Cisco – Understanding ‘Normal Burst’ and ‘Maximum Burst’ in Cisco CAR

ciscocisco-ios

As I understand, Cisco IOS CAR(Committed Access Rate) is based on leaky bucket algorithm(idea is exactly the same as token bucket algorithm) and the amount of bits I configure as average rate, is the amount of "water constantly leaking the bucket". For example here the average input rate-limit rate is 5Mbps:

interface FastEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop

Now if traffic rate is below the average rate, then it is always conformed. Am I correct that "normal burst" determines how large the traffic bursts can be before exceed-action is applied? So in case of example above, if there has been constant traffic rate of 5Mbps(625000 bytes in the bucket), then I could send for one second 7.5Mbps(adds additional 312500 bytes to bucket) of traffic and not a single bit is dropped? And if bytes in bucket are between the normal burst and maximum burst, then bytes are dropped based on RED-like algorithm until all the new packets are dropped if maximum burst is also full?

Best Answer

Let's calculate what we're dealing with here. CAR is basically the older version of IOS policing, so all these concepts apply to both.

Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms

The rate we want to restrict flows to is 5Mbps. The Commit Bucket is 937,500 bytes. The Burst Bucket is 1,875,000 bytes. And the buckets are refilled every 187.5 ms.

As you mentioned, IOS uses a bucket mechanism to restrict how much traffic can pass. It does not smooth the traffic to X% of interface bandwidth over an arbitrary time period! Instead, it allows full access to the bandwidth of the interface as long as you have the tokens to pay for it.

Also, since this is policing, RED/WRED are not in play. RED only happens when there is a queue to manage. There is no buffering/queuing in policing, only in shaping.

Let's deal with the Commit Bucket (Bc) first. Assume that there is no Excess Bucket (Be) for now.

* Commit Bucket Only (Two-Color Policer) *

This is a very strict policer that will only let you send within the CIR exactly; no bursting above. There is only one bucket, Bc. There are two "colors" for traffic, conforming and exceeding.

Time = 0 ms -- The bucket starts out full, with 937,500 bytes worth of tokens in it. Let's say you send 7,500 bytes across the interface. Now IOS decrements the bucket by 7,500 bytes, and the bucket now has 930,000 bytes worth of tokens in it. The traffic sent is considered "conforming" and has the "conform-action" applied to it.

Time = 187.5 ms -- We hit the Tc now, and refill the Bc bucket. 937,500 bytes worth of tokens are added. Any extra tokens spill out and are lost.

Time = 190 ms -- The commit bucket has 937,500 tokens in it. We receive 2,000,000 bytes of traffic. The first 937,500 bytes are transferred fine as the bucket has tokens for it. The remaining traffic is considered "exceeding" and is treated according to the "exceed-action". Remeber, there is no buffering in policing (that's called shaping) - you either transmit, remark and transmit, or drop.

Time = 375 ms -- We hit Tc again, and the Bc bucket is refilled with 937,500 tokens.

* Commit Bucket with Excess Bucket (Three-Color Policer) *

You can optionally add an Excess Bucket (Be). This allows the traffic to exceed the Bc bucket on a temporary basis. The overall CIR should stay the same. This is a three "color" policer: conforming, exceeding, and violating.

Time = 0 ms -- Both buckets (Bc and Be) start out full. Bc has 937,500 tokens, Be has 1,875,000 tokens.

Time = 50 ms -- 2,000,000 bytes of traffic arrives. The router first decrements the Bc bucket tokens. It reduces the Bc bucket to zero. The 937,500 bytes of traffic covered by Bc is considered "conforming" and has the "conform-action" applied to it.

That leaves 1,062,500 bytes of traffic that doesn't have tokens yet. Now the router dips into the Be bucket, and subtracts 1,062,500 tokens to cover the rest of the traffic. These bytes are considered "exceeding" and will have the "exceed-action" applied to it. In your example, the traffic would be dropped, but you could potentially remark or just transmit it.

If you're keeping score at home, Bc now has zero tokens, Be has 812,500 tokens.

Time = 75 ms -- Now, the router receives another 1,200,000 bytes of traffic. The Bc bucket is empty, so no help there. The Be bucket can help, so it covers the first 812,500 bytes of traffic with its tokens, and is now empty. This traffic is considered "exceeding" and will have the "exceed-action" applied to it.

Now the buckets are dry, but there are still 387,500 bytes left to deal with. This traffic is considered "violating" and is always dropped with CAR (You can do other things with it using MQC and the police command with "violate-action").

Time = 187.5 ms -- Now we arrive at the first Tc interval, time to fill up our buckets. A key point is that only Bc worth of tokens are refilled! The Bc bucket is filled up first to 937,500. The Be bucket REMAINS EMPTY.

Time = 375 ms -- It's been quiet, and we make it to the next Tc interval. Bc worth of tokens are added to the Bc bucket. Since the Bc bucket is already full, the excess tokens aren't lost - they're "spilled over" to the Be bucket instead. Now the Bc bucket is full with 937,500 tokens and the Be bucket is partially full with 937,500 tokens.

Time = 562.5 ms -- Quiet still, and we're at the next Tc. Bc worth of tokens are added to the Bc bucket, which is already full. All of it spills over into the Be bucket (which already has 937,500 tokens). The Be fills all the way up to 1,875,000 tokens.

* Final Notes *

  • Your configuration isn't making use of the Be bucket. You are rate-limiting/policing using only the Bc bucket, which may have unintended side effects if the policer/shaper sending data to you isn't configured identically and isn't in sync Tc-wise.

  • CAR/rate-limit is very old and deprecated. Consider switching to MQC and modern QoS to implement this, as it will give you more information and options.

  • I totally ignore serialization delay (the time it takes to transmit data on the line) above, and I'm quite sure the math doesn't work out in a real scenario. But the concepts are solid regardless of the exact numbers in use.

* MQC Example *

policy-map PM-FA0/0-IN
 class class-default
  police cir 5000000 bc 937500 be 1875000
!
interface Fa0/0
 service-policy input PM-FA0/0-IN
!

* Sources *

Related Topic