CAR of Committed Access Rate is like CB Policing in many respects. As a technology is allows us to apply traffic policing inbound and outbound on an interface. Unlike CB Policing however it does allow us to nest conditions to we can set maybe a global interface rate then make the access rates more specific for certain protocols...pretty neat. CAR is a two way policer though, there is no violate action.
Finally, CAR is considered legacy however so make sure you have a look at the MCQ!
Here are the obligatory 'scary' acronyms to get the blood rushing.
CIR = Committed Information Rate
Bc = Bytes Conformed
Be = Bytes Excess
Tc = Time Conformed or Time Interval
AR = Access Rate (the maximum bandwidth of the wire)
And the even more 'scary' formulae
CIR = Bc/Tc
So, CAR what is it then? Well it's the network traffic police! CAR is a rate limiter very much like the traffic police or crowd control security can reduce the 'flow' of traffic into a road or the 'people' into a Bon Jovi concert. Reducing the amount of product X going into road/gig/wire Y can help an overcrowding situation. See, it's a good when that the peelers pull over the road hog? Well yes unless its YOU! Right, lets get back to bits. Imagine we've got a 64k wire and we don't want to allow the router to grab all available bandwidth...maybe we want to allocate a quarter of the bandwidth outbound. Well thats good, we've got CAR!
OK so normally a router will push data out onto the wire at the maximum rate it can, this is the Access Rate and is calculated in terms of one second (Kbps, bps, Mbps they are all 'per second right?). Now when we start applying rate liming to the interface (policing not shaping) we start talking about fractions of a second. These 'time slices' are termed the 'T sub c' phonetically or just Tc to us. The maximum Tc we are allowed is 1/8th of a second or 125ms so we can only work down from there. The point of slicing the second means we can send fractions of the normal rate e.g. 64kbps / 8 = 8kb per Tc at 125ms. If we send data at the maximum rate defined per time interval then we'll be managing ourselves for maximum throughput. Crucially however we can stop sending data for one time period and send more in the next interval so long as we don't send more data in that one second we're good to go.
Policing is often brought back to the 'buckets' analogy but in todays speak we tend to move away from bucket...there are so many different size and colours and some have holes! For the sake of sanity however lets go down that bucket road again. Imagine at the start of the time interval you have a bucket full of tokens. Those tokens are equal to the Bc value and you have a finite amount of them. During the time interval as data needs to be sent they pay to get onto the wire by removing tokens from the bucket. When all the tokens are gone from the bucket within that time period then no more data can get onto the wire and the data is dropped (unless we configure another bucket for those 'exceeding' packets).
Right, I think we're had enough background lets get down to some configuration!
We've got a small circuit here at 64kbps. We're going to rate limit ICMP traffic down the wire to no more than half (32kbps) of the available bandwidth. The remaining traffic is free to use what it can when it can..no policing.
We need to match the traffic first so lets write out the access-listaccess-list 100 permit icmp any any echo
access-list 100 permit icmp any any echo-reply
OK this matches any TCP packet going to any remote web server running on the default HTTP and HTTPS ports (remember we're rate limiting OUTBOUND traffic but not inbound...considering most HTTP web traffic is coming back at you with images, web pages, video etc we really should limit inbound shouldn't we?). We'll stick to it and work out the bits per second we need to restrict the matched traffic in access-list 100 to 32kbps.
We want to police a 32kbps rate on the wire outbound. so here are some numbers we know.
CIR = 64kbps
Bc = 32kbps
Tc = 125ms or 1/8th second (if you need to work out the 'th' value then you take the 1000ms in one second and divide by the number of ms 1000/125=8)
The rate-limit command allows us to specify the bits per second (our target rate), the bytes per time interval for normal (Bc) and excess burst (Be) but not the time interval itself. Having said that there is nothing to stop us using the Tc to work out how many bytes per Tc we need to send. The rate-limit function also allows us to describe what we are going to do with the traffic which meets our traffic commitments or not as the case may be. OK so here is our statement.rate-limit output access-group 100 32000 1500 2000 conform-action transmit exceed-action drop
So what are we saying here? The first part after the access group is our limited rate allowing us to send web traffic requests at 32kbps (this figure is in bits per second). Next we have the normal burst value but this (unusually and annoyingly) is in bytes. Then we have the excess burst again in bytes (if the excess burst and normal burst values match then excess burting is turned off). Finally we say what we want to do with the traffic which meets these targets. Normal burst traffic is allowed to get on the wire (transmit), excess burst is dropped.
Cisco actually help us out with our maths here and suggest that your Bc value should be CIR * 0.125 (convert bits into bytes) * 1.5 (typical RTT) which for us means 32000 * 0.125 * 1.5 = 6000 bytes. Even more than that they say the Be value should be 2 * Bc so 2 x 6000 = 12000 bytes. So our configuration is going to be:rate-limit output access-group 100 32000 6000 12000 conform-action transmit exceed-action drop
So hang on why have we configured 6000bytes for normal? That makes 48000 bits per second right?! But I wanted 32000bits? Well yeah thats how it is by the Cisco numbers. Remember this is just a starting point for you. Your average RTT (round trip time may not be 1.5 seconds) so the numbers will change. All guess I can say is that Cisco say make the Bc and Be numbers like that...and thats a good place to start. If you want to go by the book and work it out so your bytes match for the Bc and Be then you need to adjust them down to fit the 32000 bits you have (i.e. 4000bytes). So we're going to push this into our router now and then test the throughput. we are expecting 32kbps to be sent so we'll throw an ICMP ping packet outbound with a payload of 100B, then 200B then 400B...so when will it stop working and run out of headroom?
Here's some more maths:
CIR = 32000bits per second = 4bytes per ms
Bc = 6000bytes which is refilled every Tc at the rate of 4bytes per ms
So how quickly will the bucket get emptied?
First work out drain rate:
What is the average RTT for ICMP to the destination?
So it's around 4ms but it can be anywhere between 1 and 32! - OK we'll go with the average.
Average RTT is 4ms and CIR fill rate is 4bytes per so 4*4 = 16bytes
Second we need the offset:
We are going to ping out with 100byte ICMP packets and we know our drain rate was 16bytes per interval so 100-16 = 84bytes
So now we can work out when it'll start dropping packets?
Time till we run out is Bc - Offset = 6000/84 = 71.42 packets.
So this is all averages right? We can't have 71.42 packets so we should see on average 71 ping packets whiz out and number 72 be dropped. When the bucket is filled up again we're off yeehar!
Let give it a whirl:
First we'll create the access list to match the ICMP traffic outbound
Now under the interface we add the CAR rate-limit statement
OK now thats all setup we'll test it with ping. Now we can use the 'size' and 'repeat' keywords to make this work for us. We are expecting pings to fail on or around 71 right and the pings are going to be 100bytes big which is the default anyway.So lets throw 80 pings of 100 bytes...
Hmm I got 74 packets...not quite the 71 I was expecting but you know what...thats close enough. It all comes down to the average RTT, the numbers all work around that.
So are we rate limiting at all?
Here is a ping a result with rate-limiting on sending 1000bytes ICMP packets with a count of 10.
70% success rate. Now we'll remove the rate-limit line from the interface and ping again.
100% success rate, no drops.
Good luck with your studiesAddendum
Cisco actually suggest that due to the 'averaging' affect of TCP traffic over a period that you over-egg the amount of data to rate-limit by a factor of 1.5. Here is a screenshot from the page and a link back to Cisco for the whole story.