05-13-2022 07:37 PM
With reference to token buckts does 'burst in msec' below refer to byte size?
police cir percent percent [burst-in-msec] [bc conform-burst-in-msec ms] [pir percent] [be peak-burst-in-msec ms] [conform-action action] [exceed-action action]
[violate-action action]
no police cir percent percent [burst-in-msec] [bc conform-burst-in-msec ms] [pir percent] [be peak-burst-in-msec ms] [conform-action action] [exceed-action action]
[violate-action action]
cir | Committed information rate. Indicates that the CIR will be used for policing traffic. |
percent | Specifies that a percentage of bandwidth will be used for calculating the CIR. |
percentage | Specifies the bandwidth percentage. Valid range is a number from 1 to 100. |
burst-in-msec | (Optional) Burst in milliseconds. Valid range is a number from 1 to 2000. |
https://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_n1.html
Solved! Go to Solution.
05-14-2022 04:05 PM
Okay, let's starts with Cisco's document Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting
What we're interested in is the interrelationship between CIR Tc and Bc, specifically Tc = Bc / CIR (in seconds)
In "original" police statement we specify the CIR and Bc and "The value of Tc defines the time interval during which you send the Bc bits in order to maintain the average rate of the CIR in seconds." I.e. to configure the Tc, as we desire, we needed to divide Bc by CIR.
Besides needing to compute the proper Bc to determine the Tc we desired, if we changed the CIR, we needed to recompute the Tc.
The newer/later syntax allows us to define the Tc directly. (The newer syntax also specifies the CIR as a percentage rather than as bps.
BTW, in the document you reference, the older form of the police statement is also documented. Further, in the percentage and millisecond form of the command, in that command's Usage Guidelines, you'll still find mention of CIR/PIR in bps.
Again, this form of the police command, is just a different way to configure the same action, but possibly in an easier or more multi-interface compatible way of doing so.
05-15-2022 08:09 AM
"It seems as it is specifying the interval in milleseconds totake the tokens and apply them to conform of the packet. Which means higher milleseconds cam mean higher processing time but lower drop rate."
It doesn't matter whether Bc is defined in bytes or milliseconds, basically they both cause the same effect.
"Higher" milliseconds I would expect to be more likely (but possibly not) to lead to lower processing time. As to effect on drop rate, that's an it depends answer.
Let's me explain another way of understanding how policing (and shaping) work.
Let's assume we have a 100 Mbps link but we want to transport data as if it were a 10 Mbps link. How do we do this?
For starters, always keep in mind the 100 Mbps link will always transmit at 100 Mbps (disregarding actual multi-speed interfaces).
We can make the 100 Mbps link behave (somewhat) like a 10 Mbps link if we somehow only allow it to transmit only 10% of the time.
Hmm, 10% of what time? A day, an hour, a minute, a second or some fraction of a second?
Starting with a second, as the time interval, a 100 Mbps link can transmit 100,000,000 bits in a second, while a 10 Mbps link can only transmit 10,000,000 bit a second. So, all we need to do, is count bits to be transmitted, each second, and drop (police) (or shape [queue]) any excess during each second.
Realize, during the second being measured, the 10,000,000 bits could all be transmitted during the first 100 milliseconds, the last 100 milliseconds, or scattered across the one second interval.
Every second, we start, again, checking bits to be transmitted again against our allocated amount of 10,000,000 bits for each second.
For what's I've just described, Tc would be 1 second and Bc would be 100 milliseconds or 1,250,000 bytes (NB: both 10% of the 100 Mbps link capacity for 1 second), i.e. Bc is the maximum amount of bits allowed to be transmitted during out Tc of 1 second, either as a total bit/byte count, or the (total) time to transmit that number of bits/bytes at physical link speed.
I'm not going to go into all the whys of selecting the Tc value (beyond noting a full second is probably very excessive), but suppose you wanted the Tc to be 10 milliseconds, while still emulating a 10 Mbps transmission rate. If so, as 10 millisecond is 1/100 of our prior Tc (of a second), Bc would also need to be 1/100, i.e. either 1 millisecond or 1,250 bytes.
If we want to emulate a 20 Mbps link (on the 100 Mbps link), while still keeping Tc at 100 milliseconds, Bc would be twice what is was, i.e. 2 milliseconds or 2,500 bytes.
05-14-2022 06:33 AM
Bump
05-14-2022 08:34 AM
Yes and no. Policing (or shaping) parameters basically all boil down to the same thing, although they, at least in later IOS variants, might be specified differently.
What policing (or shaping) does, is consider some time period (base time period usually denoted as "Tc"), and the amount of overall capacity used during that time period.
Specifying Tc in milliseconds (and capacity usage in percent), is actually just another way than specifying in bytes (and bps), but with either, you end up with the same policing (or shaping) enforcement.
If the prior doesn't answer your question, perhaps because it's unclear how policing (or shaping) do their enforcement. If so, let me know and I'll try to clarify further and/or provide additional reference(s).
05-14-2022 11:58 AM
I would appreciate an example to help further clarify
05-14-2022 04:05 PM
Okay, let's starts with Cisco's document Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting
What we're interested in is the interrelationship between CIR Tc and Bc, specifically Tc = Bc / CIR (in seconds)
In "original" police statement we specify the CIR and Bc and "The value of Tc defines the time interval during which you send the Bc bits in order to maintain the average rate of the CIR in seconds." I.e. to configure the Tc, as we desire, we needed to divide Bc by CIR.
Besides needing to compute the proper Bc to determine the Tc we desired, if we changed the CIR, we needed to recompute the Tc.
The newer/later syntax allows us to define the Tc directly. (The newer syntax also specifies the CIR as a percentage rather than as bps.
BTW, in the document you reference, the older form of the police statement is also documented. Further, in the percentage and millisecond form of the command, in that command's Usage Guidelines, you'll still find mention of CIR/PIR in bps.
Again, this form of the police command, is just a different way to configure the same action, but possibly in an easier or more multi-interface compatible way of doing so.
05-14-2022 03:28 PM
so according to this article
https://www.networktut.com/control-plane-policing-copp-tutorial
Router(config)# class-map [match-any | match-all] class-map-name Router(config-cmap)# match [access-group | protocol | ip prec | ip dscp] ! Router(config)# policy-map {policy_map_name} Router(config-pmap)# class {class-map-name} Router(config-pmap-c)#police {rate-bps | cir {cir-bps [burst-bytes] [bc burst-bytes]| percent percent [burst-ms] [bc burst-ms]} } Router(config-pmap-c)#conform-action {drop | transmit} Router(config-pmap-c)#exceed-action {drop | transmit} |
Notes:
For the command “police …”:
– For rate-bps, specify average traffic rate in bits per second (b/s). The range is 64000 to 10000000000.
– For cir cir-bps, specify a committed information rate (CIR) in bits per second (b/s). The range is 32000 to 10000000000.
– For burst-bytes (optional), specify the normal burst size in bytes, which indicates how much the cir can be exceeded. The range is 8000 to 16000000.
– For bc burst-bytes (optional), specify the conformed burst (bc) or the number of acceptable burst bytes. The range is 8000 to 16000000.
– For burst-ms (optional), enter the conform burst size in milliseconds. The range is 1 to 2000. The default is 250 ms.
– For bc burst-ms (optional), specify the conformed burst (bc) in milliseconds. The range is 1 to 2000.
It seems as it is specifying the interval in milleseconds totake the tokens and apply them to conform of the packet. Which means higher milleseconds cam mean higher processing time but lower drop rate.
05-15-2022 08:09 AM
"It seems as it is specifying the interval in milleseconds totake the tokens and apply them to conform of the packet. Which means higher milleseconds cam mean higher processing time but lower drop rate."
It doesn't matter whether Bc is defined in bytes or milliseconds, basically they both cause the same effect.
"Higher" milliseconds I would expect to be more likely (but possibly not) to lead to lower processing time. As to effect on drop rate, that's an it depends answer.
Let's me explain another way of understanding how policing (and shaping) work.
Let's assume we have a 100 Mbps link but we want to transport data as if it were a 10 Mbps link. How do we do this?
For starters, always keep in mind the 100 Mbps link will always transmit at 100 Mbps (disregarding actual multi-speed interfaces).
We can make the 100 Mbps link behave (somewhat) like a 10 Mbps link if we somehow only allow it to transmit only 10% of the time.
Hmm, 10% of what time? A day, an hour, a minute, a second or some fraction of a second?
Starting with a second, as the time interval, a 100 Mbps link can transmit 100,000,000 bits in a second, while a 10 Mbps link can only transmit 10,000,000 bit a second. So, all we need to do, is count bits to be transmitted, each second, and drop (police) (or shape [queue]) any excess during each second.
Realize, during the second being measured, the 10,000,000 bits could all be transmitted during the first 100 milliseconds, the last 100 milliseconds, or scattered across the one second interval.
Every second, we start, again, checking bits to be transmitted again against our allocated amount of 10,000,000 bits for each second.
For what's I've just described, Tc would be 1 second and Bc would be 100 milliseconds or 1,250,000 bytes (NB: both 10% of the 100 Mbps link capacity for 1 second), i.e. Bc is the maximum amount of bits allowed to be transmitted during out Tc of 1 second, either as a total bit/byte count, or the (total) time to transmit that number of bits/bytes at physical link speed.
I'm not going to go into all the whys of selecting the Tc value (beyond noting a full second is probably very excessive), but suppose you wanted the Tc to be 10 milliseconds, while still emulating a 10 Mbps transmission rate. If so, as 10 millisecond is 1/100 of our prior Tc (of a second), Bc would also need to be 1/100, i.e. either 1 millisecond or 1,250 bytes.
If we want to emulate a 20 Mbps link (on the 100 Mbps link), while still keeping Tc at 100 milliseconds, Bc would be twice what is was, i.e. 2 milliseconds or 2,500 bytes.
05-15-2022 11:55 AM
So this is starting to make sense I believe ~
In specifying extra Bc, I am processing extra bits for more load on the cpu. This is essentially the function of the bc specification in seconds or in bits.
05-15-2022 01:26 PM
Policing (or shaping) will add CPU load on a software device, like most of the ISR. On a switch, it may be supported in hardware, i.e. little to not extra CPU impact.
Regardless "extra" Bc doesn't matter much, as you're just defining a bit (byte) value to count against.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide