Networking

Control unwanted traffic on your Cisco router with CAR

If you're sick of unnecessary traffic clogging up your network, you don't have to take it anymore. You can manage that unwanted traffic using committed access rate (CAR) -- or "rate limiting."

Committed access rate (CAR) -- or "rate limiting" -- is a method for managing unwanted traffic on your network and making sure it doesn't affect important traffic. For example, if someone is downloading a lot of Web traffic from a Web site, he or she could preclude necessary traffic from getting through -- and potentially make the production servers inaccessible over the network. Let's discuss how you can use CAR to prevent such an event.

You can only use CAR with IP traffic -- it doesn't work for non-IP traffic. To use CAR, you must enable CEF on your routers. (For more information, check out "Get better performance with Cisco Express Forwarding (CEF).")

Essentially, CAR controls the bandwidth of a certain type of traffic, and an access control list (ACL) defines which traffic it controls. Once you've created the ACL, you can set CAR to enforce a bandwidth rate on that traffic in either an INBOUND or OUTBOUND direction, according to the interface on which you applied CAR.

CAR can be very useful as a basic QoS function. For example, let's say you have a production application at a remote location across a 128-Kb WAN connection. The application works fine until, one day, a new employee gets a PC, a Web browser, and Internet access.

When in use, that single Web browser slows down the entire remote production network by downloading Web pages and documents over the 128-Kb connection. So how can you prevent the Web browsing from taking over the WAN connection and slowing down the production application?

There are many QoS functions on a Cisco router, and there are many third-party applications and appliances that can help solve this problem. However, the simplest solution to this problem costs nothing -- and only takes about two minutes to implement using the Cisco IOS and CAR.

Using CAR requires two simple steps:

  1. Create an ACL to define the traffic you want to rate limit.
  2. Use the rate-limit command, referencing the ACL on your interface closest to the source of the traffic, referencing the proper direction, and referencing the proper bandwidth amounts.

To return to our example, let's say you have a headquarters location that provides the Internet access for this single PC across the WAN. Even if browsing the Web is a necessary business function, it's negatively affecting the performance of the production application on the remote network.

Let's look at how you can control this Web traffic. First, define the traffic you want to rate limit on the headquarters' router. Here's an example:

HQ-Router(config)# access-list 120 permit tcp any eq www host    10.200.200.200

In this example, the remote PC has an IP address of 10.200.200.200. So, we're saying that the source server could be any Web server serving Web pages on port 80.

Next, use the rate-limit command on the interface. Here's an example:

HQ-Router(config)# interface Serial0/0
HQ-Router(config-if)# rate-limit output access-group 120 50000    10000 20000 conform-action transmit exceed-action drop

This applies the rate limit to the interface, referencing ACL 120. We applied it in the outbound direction because we applied it on the headquarters router (not the remote router). That's because we want to prevent unwanted Web traffic from going across the WAN to the remote site -- we don't want to wait until the traffic arrives there before slowing it down.

50000, 10000, 20000 represents the normal bits per second (bps) for this traffic (i.e., 50000 bps or about 50 Kb), the normal burst size for the traffic (i.e., 10000 or about 10 Kb), and the maximum burst size for the traffic (i.e., 20000 or about 20 Kb). The traffic must conform to these numbers in order for the router to transmit it (as specified by conform-action transmit). If the traffic exceeds those bandwidth settings, the router will drop it (as specified by exceed-action drop).

Configuring these settings on the headquarters' router on the Serial0/0 interface (i.e., the interface that goes to the remote location) limits the extraneous Web traffic to consuming less than 50 Kb of the 128-Kb circuit used for the production application.

While you can use CAR in a variety of situations, keep in mind that CAR only limits what you tell it to limit with the ACL. In addition, the CAR bandwidth settings you reference limit all traffic referenced in the ACL.

For more information, see Cisco's rate-limit command documentation, Cisco's Configuring Committed Access Rate documentation, and Cisco's "Using CAR During DOS Attacks."

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

9 comments
rahammers
rahammers

would this work with a Layer 3 switch rather than a typical router? In my case the "router" closest to the source and in fact the only router capable of inspecting the traffic due to VPN encryption is a 6500. Interesting concept in limiting "PC deployment" traffic that can't seem to get their own rate limiting system properly in place.

onebusonly
onebusonly

I would like to add a few details to the subject matter covered in this blog entry about regulating specific traffic with CAR. There are some costs (other than $$) for using this feature: Depending on the number of packets that meet the ACL or class maps/policy maps classification criteria, it will work the router?s processor extra hard as it makes classification decisions and executes the process to rate-limit that traffic. Just understand that the more comprehensive the CAR configuration, the harder the router will have to work to accommodate the rate-limiting. Yes, I know, this is elementary to most of you, but sometimes, less is more, especially with branch routers. Make sure you take into consideration what other services are running on the router (anything requiring deep packet inspection or VoIP support requires increased CPU cycles). The bandwidth configured as the ?limit? (for the web traffic in this example), is a soft ceiling. The technique a router uses to scale back the transmission of any session that meets the classification criteria is to drop packets; forcing the selected hosts and their offending applications to comply with the rate-limit. With TCP traffic, this not only works to fool the hosts into scaling back their selected transmissions, but it increases the number of packets put on the wire as the host must retransmit the very same packets that were dropped in order to satisfy the rate-limit. If your WAN link is highly utilized and supports latency sensitive traffic that you are trying to protect, rate-limited traffic can burst beyond the limit before it settles down into your configured limit. Consider supplementing your policies with RED. It is a feature to help manage the packet drop probability. CAR is death for important UDP packets. UDP has no retransmission or error correction capabilities, so be careful what applications, port numbers or host addresses you include in your lists. If you are too general, you may include important UDP traffic that can?t recover. Specific filters are better. The author properly pointed out that there are specialized third-party applications and appliances that can perform this function. For business critical traffic management, look for products that are flow and session aware. If you require a more sophisticated application acceleration or optimization product ?. well, that?s a whole ?nother blog.

BALTHOR
BALTHOR

They each have an Internet Explorer Internet access.If every computer downloads at the same time you are telling me that the download speeds would decrease.I see AT&T's two wire satellite system as undaunted here."As many computers as you got---".

cobaugh.harvey
cobaugh.harvey

The author must have forgotten that the CAR settings of 50000, 10000, 20000 do not all refer to bps. Only the 50000 is in bits per second. The normal burst and Max burst values are in bytes per seconds. In order to get the recommended Cisco value you would multiply 50000 by 1.5 = 75000, then divide by 8 to get 9375 (BYTES). The same math would apply to the maximum burst but the multiplier is 2 times the normal burst, or 18750 BYTES. The resulting configuration entry would have 50000 9375 18750.

murilo.coutinho
murilo.coutinho

Hi David, I got a little bit confused about these "burst sizes" (50000,10000,20000). Is it possible for you to explain it better? Thanks Murilo

onebusonly
onebusonly

Obviously VPN traffic can't be deep inspected. If you want to limit multiple VPN tunnels and the sessions within, you would have to associate each VPN with an IP address or range/subnet and rate limit each session inside of that tunnel. You could only do that on the trusted/non-encrypted side of the session. A router or L3 switch is not the best tool for that. A session aware traffic manager would be the best choice.

kamal kr
kamal kr

Ok, thanx, but can we kill a session of particular ip, who downloading form internet via command, if yes, then respond on same

CrimsonPaw
CrimsonPaw

Another option for BALTHOR would be to use classmaps assigned to a policy map on the router. That way you can police your web traffic when other traffic is present. Granted if you're not on a WAN that support COS (i.e. MPLS) it won't matter once it hits the WAN, but you can still prioritize on the router.

onebusonly
onebusonly

You just need a restrictive ACL for that. I think that's what you are asking.