Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.


Hi Guys

i have to rate limit the bandwitdh from a specific subnet going to a particular server.i plan to use MQC policing so whts u r advice this.

I am confused abt some terms in rate-limiting.

i understand the confrim action and exceed action not sure for wht the burst size is used.A simple explanation will be helpful with a example.



Super Bronze

Re: rate-limiting

"i have to rate limit the bandwitdh from a specific subnet going to a particular server.i plan to use MQC policing so whts u r advice this. "

Before providing advice, I would first ask why rate limit? The reason I ask, because often there are better ways to accomplish a particular goal rather than rate limiting (although not always).

". . . not sure for wht the burst size is used.A simple explanation will be helpful with a example. "

Have you read the Cisco TechNotes and White Papers? For instance:

If you have read such and similar documentation, the importance of Bc and Tc still might not be clear. (NB: hopefully the the formula: Tc = Bc/CIR [in seconds], is clear.)

What might help in understanding the importance of time intervals is, assume you want to rate limit a link's (or some traffic's) bandwidth to 20%. Assume we can send 5 maximum sized packets in 1 ms. If Tc is set to 1 ms, during any one ms, any one packet can be sent at any time during that 1 ms, but two packets could not be sent back-to-back unless the first packet ended at precisely the 1 ms mark and the 2nd packet started also precisely at the 1 ms mark (keep in mind, much network traffic is often "bursty", i.e. packets back-to-back isn't unusual).

If we increase the Tc to 2 ms, two packets can arrive any time during the 2 ms period, including back-to-back, yet the problem arises again for 3 or more packets back-to-back. So, all we need to do is keep increasing Tc?

No, because the problem continuing to increase the Tc, might be seen if we increase it to 100 ms which now allows 100 packets any time during the 100 ms, including all 100 back-to-back, or 200 back-to-back if half fall precisely on each side of the 100 ms interval. But, if we transmit 200 packets back-to-back, for that 40 ms, the link is 100% busy yet we're trying to limit bandwidth to 20%!

So, setting Bc which indirectly sets Tc, is a trade-off on how closely we regulate the traffic rate. Smaller values more closely match a link of that bandwidth, but tend to adversely impact "bursty traffic".

In the reference I provided, note the graph showing how policing (rate limiting) clips the highs, yet for traffic like TCP, it's really worse because of the way TCP responds to drops.

Re: rate-limiting


Thanks for u r reply.

Actually we are seeing on one of our links tht is more utilized by this subnet.

The traffic from this subnet destined to the server is very high,so we would like to restrict the bandwitdh for this subnet and the rest of the traffic should not be impacted.

Cau you advice wht else we can use beside rate-limit one thing tht comes to my mind is to define this traffic in priority queue grant it some bandwidth and give the other bandwidth to default class.



Super Bronze

Re: rate-limiting

If you equipment supports it, then usage of a queuing method, other than FIFO, that keeps some high bandwidth flows from monopolizing all the bandwidth would be a better solution, I think.

If the equipment is a router, something like FQ is a great starting point. For something like a switch, shared mode SRR (again if supported), is a great starting point. Both can be configured to allow your high bandwidth demanding traffic all the available bandwidth, but still permit other traffic the bandwidth it needs.

If only something like rate-limiting or policing is available, yes it can be used to cap some traffic's bandwidth demand leaving bandwidth for other traffic. 4 problems though, 1) it doesn't allow capped traffic to use all available bandwidth, 2) whatever you chose as the cap limit might not always allows sufficient bandwidth for all traffic (e.g. you limit to 75%, "leaving" 25%, but is 25% always sufficient for all your other traffic?), 3) (as noted in my prior post) it can have a very adverse impact to the traffic it limits; much more so than its nominal rate cap, 4) because of bursting, other traffic can still be impacted even while traffic is capped (this is generally short term, but can be important if other traffic is something like VoIP).

Re: rate-limiting


I plan to implemet the below config.I need to understand few terms in the config.

access-list 101 permit ip any host x.y.z.1

class-map SMS

match ip address 101

policy-map SMS-P

class SMS

police police 8000 1000 1000 conform-action transmit exceed-action drop

then apply it under the interface in inbound direction.

now my confusion is about the vlaues i mean wht do they repesent i.e 8000 1000 1000

can anyone explain in brief please.



Super Bronze

Re: rate-limiting

"now my confusion is about the vlaues i mean wht do they repesent i.e 8000 1000 1000 "

8000 is CIR, in bps

1st 1000 is normal-burst-bytes

2nd 1000 is maximum-burst-bytes

That's what they are, in brief.

Much additional information is available if you search the Cisco site. This documentation well explains what these parameters are, and what they control. What's not clear, I believe, is how to use them (beyond CIR), which I tried to briefly explain in my first post, and why rate-limiting or policing might not be the best option for your requirements in my second post.

If you still have confusion on the parameter meanings, perhaps another poster will be able to answer better.


BTW, if SMS is Microsoft's SMS, and the issue is update "pushes", I've also used policer's to regulate it. It was the only tool I effectively had, and indeed there were still the issues I noted in my 2nd post, but at least with SMS, it's a "background" bulk transfer, that less than optimal treatment to its traffic doesn't stop it from eventually getting transfers across. For this type of traffic, if you're going to use policing, by choice or need, default Bc/Be should be reasonable, but carefully consider CIR, which you might need to keep adjusting to balance best effective throughput of SMS vs. impact to other traffic.