With the settings you listed above you're specifying a 10-Mbps average rate, with normal burst size of 20-MBytes/sec (equals 160-Mbps) and excess burst size of 20-MBytes/sec (equals 160-Mbps). Burst sizes are specified in bytes, not bits.
So bursts to at least 20-Mbps are easily covered by those values. If your router interfaces are Fast Ethernet, ATM OC-3c, or slower, you aren't really limiting your rates with those numbers.
What kind of Cisco device are you trying to run rate-limiting on? If you're not seeing traffic getting past 10-Mbps, either the speed of the interface or the routing CPU is holding you back. Also: how are you measuring the throughput?
According to the Cisco IOS Quality of Service Solutions Command Reference, Release 12.2, under "rate-limit":
With the listed choices for parameters, extensive test results have shown CAR to achieve the configured rate. If the burst values are too low, then the achieved rate is often much lower than the configured rate."
So, to achieve a configured average rate of 10,000,000 following Cisco's recommendations, you would use
10000000 1875000 3750000
Similarly, to achieve a configured average rate of 20,000,000 you would use
20000000 3750000 7500000
Now, to reach your goal of 10-Mbps with burst capability to 20-Mbps, you could specify
10000000 2500000 2500000
where 2,500,000 bytes is 20 megabits exactly, and have an "achieved rate" that may be lower than configured rate. Or, you could mix and match the numbers, using the average rate from 10-Mbps and the burst figures from 20-Mbps average rate:
10000000 3750000 7500000
but that would probably result in traffic rates being over 10-Mbps on average.
I would try:
10000000 2500000 3750000 (for occasional bursts)
10000000 3750000 3750000 (for frequent bursts)
Let's say you have a FastEthernet1/0 interface running 100 full duplex. If you're able to generate a sustained traffic stream across the interface of over 20-Mbps and the router CPU is not holding you back, then the "show interface FastEthernet1/0 rate-limit" command should indicate that you've had some packets that exceeded limits imposed by the burst values and were dropped.
Interesting. There's a 7206 VXR NSE-1 on one of my networks, rate-limiting on a Gig Ethernet interface too (although not sub-interfaced). It rate-limits by ACLs, matching each customer's assigned IP address range and capping their Internet throughput according to what their contract calls for.
MRTG is used to monitor the overall bandwidth of the Gig interface, to make sure we're getting the rate we're paying for from our upstream ISP (27-megabit committed out of a 100-megabit Fast Ethernet pipe).
Could it be that your MRTG graph needs to have its scaling parameters adjusted, so that you can see traffic above 10-megabit? I don't handle the MRTG system programming here, so I don't know if that even makes sense, or is possible. But I do know that one time on another ISP link that is monitored with MRTG, when the upstream ISP cut the bandwidth to 5-megabit we could definitely see the plateau. And it was obvious when they returned the speed to the previous level: we started seeing peaks and valleys again as traffic shot up past the 5-megabit limit.
I happened to see this post here. I am having a question for the CAR. Are the Bc/Be here same as Bc/Be in traffice shaping? In traffic shapping Bc/Be is defined per interval, not per second. By reading this post, it seems CAR Bc/Be is bytes/sec? If it's per second, for how long the CAR allow the burst traffic? What about I am sending a 100Mbytes traffic. Will it allow 5 seconds burst? How do can control this in the CAR, I mean the burst length?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...