When policing traffic for your customer at 500 Mbps, you can use either a single-rate two-color or a single-rate three-color policer. These policers work by using a token bucket mechanism to control the rate of traffic.
In the case of single rate two color policer, it uses a single token bucket to control the traffic rate. When a packet arrives, it checks if there are enough tokens in the bucket to cover the packet’s size. If there are enough tokens, the packet is allowed to pass (conforming), and the tokens are removed from the bucket. If there are not enough tokens, the packet is dropped (exceeding).
In the case of single rate three color policer, it uses two token buckets: one for conforming traffic and one for exceeding traffic. When a packet arrives, it first checks if there are enough tokens in the conforming bucket. If there are enough tokens, the packet is allowed to pass (conforming), and the tokens are removed from the bucket. If there are not enough tokens in the conforming bucket, it checks the exceeding bucket. If there are enough tokens in the exceeding bucket, the packet is marked as exceeding (e.g., set to a lower priority), and the tokens are removed from the bucket. If there are not enough tokens in either bucket, the packet is dropped (violating).
In both cases, if a packet arrives and its size is higher than the total tokens available, the packet will be dropped in the case of a two-color policer, or it will be marked as exceeding in the case of a three-color policer.
Firstly, I think in you reply you explained single rate two color and dual rate three color not the single three color am I correct ?
secondly, I want to understand how the first token goes to the bucket, based on your reply it is like there are tokens in the bucket even before the first packet arrive (the tokens are there in the bucket even before any packets popup? ) am I missing something here because for me a token added to the bucket based on arrived packets? or it doesn’t work like that ?
Actually, I was describing single-rate three-color, but I used the terms CIR and PIR incorrectly because those are used for dual-rate three-color, and I believe that is where the confusion lies. I will fix my answer above to be correct. The lesson clearly describes the difference between these two policing mechanisms.
Initially, when you power on the devices, and before any traffic has traversed a police link, the bucket is full. For this reason, the very first packet that arrives will find the bucket full of tokens. Secondly, remember that the replenishing of the bucket does not depend upon arriving packets, but it depends upon the time elapsed between packet arrivals. So it is not the arrival of packets that replenishes the bucket, but it is the passage of time that does so.
So packet arrival removes tokens, while the time between packet arrivals replenishes. Does that make sense?
In Single Rate - Two Bucket , Which is the criteria to spill tokens from de Bc Bucket to the Be Bucket ? is based on certain inactivity ? How max bucket token quantity is calculated ?
Take for example, 2 secs between packets it means the replenish tokens will be twice and if the 1st bucket has a max quantity it splills this tokens to the be bucket ?
In the Single Rate - Three Color model (which has two buckets), tokens are spilled from the Bc (Committed Burst Size) bucket to the Be (Excess Burst Size) bucket when the Bc bucket is full. This is not necessarily based on inactivity, but rather on the rate at which tokens are being replenished and utilized.
The maximum bucket token quantity is calculated based on the Committed Information Rate (CIR) and the time interval (Tc), which is typically 1 second. The formula is Bc = CIR * Tc. But this can be adjusted.
In your example, if there are 2 seconds between packets, the replenish rate would indeed be twice the CIR. If the Bc bucket is already at its maximum capacity when the new tokens arrive, the excess tokens will spill over to the Be bucket.
I have one doubt about the order of replenishing tokens and take out tokens from the bucket.
Taking this excerpt from this Lesson :
Imagine a policer configured for 128.000 bps (bits per second). A packet has been policed, and it takes exactly 1 second until the next packet arrives. The policer will now calculate how many 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 fewer tokens you’ll get. When the bucket is full, our tokens are spilled and discarded.
When 2nd packet arrives, difference between pckt 1 and a pckt 2 is 1 sec , applying the formula the replenish tokens will be 16000 Bytes. But here is my doubt : 2nd packet arrives but the bucket is empty because is the first time the router applies the policer, only at 2nd time if pckt size is < tokens in the bucket, the policer will take out 100% tokens (16000) and then replenish the bucket based on the difference between packet 3 and packet 4.
When the second packet arrives, the bucket is not empty. It has 16000 tokens because of the 1 second of time between packets. Have I misunderstood your question? If so, can you clarify?
I am a little confused about Policing. My first question would be, under what principle does policing work? Does it monitor the amount of bandwidth that’s being used or the actual transmission speed?
In other words, if we had a 1000mbit/s link and our CIR was 200 mbit/s, would we be able to transmit 150mbit/s of data using 1000mbit/s as our transmission speed?
Now, what exactly are the steps that a router configured for policing takes? When a packet is received, will it first calculate how many tokens should it put in the bucket, then it puts them there and then check if it has enough tokens in the bucket for the packet to be allowed? And when exactly is the bucket emptied of the tokens? This process just feels a little confusing to me.
My next question is, the amount of bytes (tokens) the device puts in the bucket is not based off the size of the received packet, right? In other words, the router could receive a 1000B packet but put a different amount of bytes into the bucket as calculated using the policing formula.
And my last question is, why is it that the more often we receive packets and replenish the bucket, the fewer tokens we’ll get? I originally assumed that more tokens would be added into the bucket since we are receiving packets at a faster data rate…
What is meant by congestion with PIR? That our site or the ISP site is congested?
Why should we use the dual-rate three color bucket, instead of single-rate three color bucket? Is that because we could use the PIR more often while were not congested?
Why is the PIR twice as much as the Bc bucket in dual-rate three color policing?
Congestion in general occurs when the actual data rate exceeds the allowed data rate of the interface in question. In the context of policing, congestion occurs when the rate at which data arrives at the policer exceeds the allowed data rate. Any packets exceeding that data rate are dropped. Now when we have dual rate three color, where a CIR and a PIR are configured, we consider the policer “congested” whenever packets need to be dropped. This may occur at the CIR or at the PIR. However, it depends on the parameters that are configured for the exceed-action and violate-action parameters which configure what happens when the CIR is surpassed, and when the PIR is surpassed, respectively. See the following lesson for configuration details:
Note that congestion will take place at the location where the policer is configured, that is on our router and not on the ISPs router. Note also that if no exceed or violate actions are configured, packets will not be dropped at the CIR and PIR rates, and thus congestion will not occur at the policer.
Dual rate three color gives us more granularity in the configuration than the single rate three color. You have two thresholds that you can configure, the CIR and PIR, and allows for two burst sizes, a Bc and a Be that is set by the IOS operating system. Dual rate is more suited for complex networks requiring detailed QoS configurations, while single rate is apt for simpler network setups.
This was just the example that Rene used. You can set the PIR to be any size, as long as it is larger than the CIR.
Think about it this way. During the 1 second delay between the arrival of the 1st and 2nd packets, the token bucket is being continuously replenished. It’s not suddenly replenished with 16000 tokens when the second packet arrives, but it is a continuous flow. So at 0.1 seconds, we’re at 1600 tokens, at 0.2 we’re at 3200 at 0.3 we’re at 4800 and so on. When the second packet arrives, the level of the token bucket is checked and that value is used. So replenishing takes place continuously, and removal of tokens takes place instantaneously when a packet arrives. Does that make sense?
Policing in networking works by monitoring the data rate for a group of packets (a flow). It does not monitor the actual transmission speed, but the amount of data being transmitted over a period of time. If the data rate exceeds the configured limit or CIR, the excess packets will be dropped.
If you have a 1000Mbit/s link and your CIR is 200Mbit/s, you can transmit data at any speed up to 200Mbit/s without experiencing any policing. If you try to transmit at 150Mbit/s, that would be within your CIR, so the policing mechanism wouldn’t take any action.
Concerning your next two questions:
Token replenishing is based on the time between arriving packets.
Token removal is based on the number of bytes in the arriving packet
Tokens are replenished over time while they are removed upon the arrival of a packet.
Because replenishing is based on time and removal is based on the arrival of packets and their sizes. The more time we have between packet arrivals, the more the bucket is replenished. So if you have packets arriving more often, and you thus have less time between arrivals, you will generally have fewer tokens replenishing the bucket. Does that make sense?
In this case, the be bucket is filled by the tokens spilled from the bc bucket but… Be bucket also has the same amount of token of bc bucket ?
Take for example an ingress pckt is > 16000 Bytes (CIR 128 Kbps), it exceeds bc and therefore tokens from the be bucket has to be taken or not if the packet exceeds the be bucket (violating)
QoS Policing Dual Rate , 3 colors , 2 buckets:
In this case, both buckets work in parallel and they are replenished using the same formula (pckt arrival - previous pckt arrival) * police rate / 8
Take for example :
CIR = 128 Kbps
PIR = CIR * 1.5 (192 Kbps)
Tokens for CIR Bucket = 16000 Bytes
Tokes for PIR Bucket = 24000 Bytes
Pcket ingress = 20000 Bytes exceeds CIR, but matches PIR
In the single rate three color case, the Be (excess burst) bucket is filled with tokens that spill from the Bc (committed burst) bucket. However, the Be bucket does not have to have the same amount of tokens as the Bc bucket. Indeed, the Be bucket size is typically set based on the specific burst speed that you want to achieve.
If an ingress packet is larger than the Bc bucket (like your 16000 bytes example with a CIR of 128 Kbps), it will indeed exceed the Bc and tokens from the Be bucket will need to be used. If the packet size also exceeds the Be bucket, the packet is marked as violating and is typically dropped or marked down depending on your policy.
However, this is an unlikely and undesirable scenario, as Be and Bc sizes are generally much larger than a single packet. These are typically set by the IOS based on the CIR and the intended burst rate and would avoid such a case.
In the scenario you described, the packet is not conforming it is exceeding. In this case, tokens are removed only from the PIR bucket. The tokens in the Bc bucket are untouched.
