You’re correct that Bc (Burst Commit) is the maximum capacity of the bucket, but the calculation is not as straightforward as you’re thinking.
The formula for Bc is Bc = CIR * Tc.
Tc, the time interval, is a value that is calculated by dividing Bc by CIR. In some cases, like in the Cisco default configuration, Tc is defined as 1/32nd of a second, which is where the division by 32 comes from in the OCG.
So if we’re using a Tc of 1/32nd of a second and we want to calculate BC, we’d multiply the CIR by 1/32nd of a second. This gives us the number of bits that can be sent during that time interval.
So, in your case, the Bc value would indeed be 16,000 bytes (or 128,000 bits) if we were simply converting bits to bytes. But because we’re calculating the number of bits that can be sent in a specific time interval (1/32nd of a second), we use the formula Bc = CIR * Tc.
Rene primarily uses Cisco CML to create and execute lesson labs. However, you can easily use GNS3 to perform this and other QoS lesson labs.
Here are some commonly recommended router images that support extensive QoS features:
Cisco IOSv
Image:iosv-l2-adventerprise
Pros: It is lightweight, supports a wide range of features including advanced QoS, and is officially supported by Cisco in GNS3.
Usage: Ideal for simulating various network topologies and QoS configurations.
Cisco IOSvL2
Image:iosvl2
Pros: Specifically designed for Layer 2 switching with robust QoS support. It is also lightweight and efficient.
Usage: Best for scenarios requiring advanced Layer 2 QoS features and VLAN configurations.
Cisco IOS-XE (CSR 1000v)
Image:csr1000v-universalk9
Pros: This image runs Cisco’s IOS-XE software, providing a rich set of QoS features and high performance, making it suitable for enterprise-level simulations.
Usage: Recommended for complex QoS configurations and high-throughput simulations.
Cisco IOS (Classic)
Image:c3725-adventerprisek9-mz
Pros: Supports a comprehensive range of QoS features and is widely used in network labs for educational purposes.
Usage: Suitable for general QoS lab exercises and configurations.
Recommendations:
For simplicity and versatility: Start with iosv-l2-adventerprise or iosvl2.
For advanced features and enterprise-level configurations: Use csr1000v-universalk9.
Thanks for great lesson. According to Cisco and this lesson, the bucket sizes are left by default to 1/4 th of the CIR. However , is configurable.
I have a question: if the bucket size is the same or lower than the CIR (even though a different value in bytes, but same value in bits) then this " generates" a rule:
Packets going to the policer must NOT have a greater size than the bucket, or otherwise they will ALWAYS be declared non-conformant (exceeded or violating ). Even on a burst!!Or even if we are transmitting slower than the CIR but with packets sized bigger than the bucket!!
So if I configure the size of the bucket to be bigger than the CIR, then I can override this rule and I can have bursts due to the size of the packets being greater than the CIR, but the time interval between packets will still be 1 second. Otherways, In could only have bursts due to a shorter time interval between packets, or due to a combination of time interval and packet size, but again, the packet size could NEVER be bigger than the bucket size.
It is true that the bucket size should be configured to be of greater size than the largest expected packets, otherwise, any packets larger than the bucket will be non-conformant as you suggest, regardless of the rate at which the packets arrive.
Remember however, that the size of the packets in normal traffic will vary depending upon the applications and the traffic type, so you won’t always see such large packets.
You’re also correct in your understanding of the relationship between the bucket size and the CIR. If you configure the bucket size to be larger than the CIR, you can indeed allow for bursts that are larger than the CIR. This is because the bucket can hold more than the rate of traffic specified by the CIR. For this reason, unless you have a specific purpose in mind, it is best to keep the default bucket size for best results.
It’s important to remember that the bucket size doesn’t just control the size of the burst, but also the duration of the burst. So, if you increase the bucket size, you’re also allowing for longer bursts of traffic at rates higher than the CIR. Does that make sense?
Hello, everyone. This is my last hope with this specific topic, so I am asking here in hopes of clarification and enlightement
I have one question. What exactly do the time intervals (TC) accomplish in policing? In shaping, they define the on-off periods, so when we transmit data (remove tokens from our buckets) and when we stop transmitting data (when the buckets are empty).
In shaping, it makes perfect sense since shaping works on a principle where we send some data, stop, send, etc. However, why is there a time interval in policing? What does it do?
ISP#show policy-map interface G0/0 input class ANY
GigabitEthernet0/0
Service-policy input: POLICE
Class-map: ANY (match-all)
56 packets, 75284 bytes
5 minute offered rate 2000 bps, drop rate 2000 bps
Match: any
police:
cir 128000 bps, bc 4000 bytes
conformed 43 packets, 56902 bytes; actions:
transmit
exceeded 13 packets, 18382 bytes; actions:
drop
conformed 2000 bps, exceeded 2000 bps
ISP#
The reason why I am asking is because I thought that the bucket in policing is filled up with tokens up to the CIR. However, the size of the bucket is basically the BC value, or not? Which is 4000 bytes in my image above, which isn’t what I configured my CIR to be (128000 bits so 16000 bytes).
It turns out this also has to do something with the TC in policing, which is 1/4 of a second. If you convert 128000 bits into bytes (divide it by 8 and divide it by 4 (because of the TC), you actually get the BC value.
I hope you understand what I am trying to say. I am not quite sure what the TC really is for in policing.
In policing, tokens are put into the bucket based on the amount of time that has elapsed between the arrival times of subsequent packets, as described in the Policing Explained lesson.
Internally to the router, the algorithm used for this replenishing uses the Tc to determine the rate at which tokens are added to the bucket. Most Cisco devices will use a default Tc of 1/4 seconds. This value is chosen based on the fact that it is short enough to enforce rate limits accurately and handle bursts effectively, and long enough to avoid excessive computational overhead from frequent token bucket updates.
So every Tc, the appropriate number of tokens are added to the bucket. Beyond this, the Tc for policing doesn’t really do much else.
The relationship between the CIR, the Bc, and the Tc can be written like so, just as you have derived in your post:
Tc = Bc/CIR
With a CIR of 128000bps, and a Tc of 1/4, we have a Bc of:
The Bc value determines the maximum amount of data that can be sent during one Tc. In your case, the BC value is 4000 bytes, which means that during each TC, you can send up to 4000 bytes of data, which corresponds to the CIR.
Now if you want to use a different Tc, you can achieve this by changing the size of the Bc, thus indirectly changing the Tc via the Bc = Tc * CIR relationship. For more information on how to do that, take a look at the police command reference:
