Rate-limiting on egress interface to ISP

Answered Question
May 15th, 2009
User Badges:

Hi, I have a question on rate-limiting. We are rate-limiting per ACL 109 which is applied via a rate-limit statement to our serial interface. I can see that for periods of time, we are exceeding our normal and excess burst.

Is there any recommended way of increasing the size of the normal and burst measurements so that less traffic will be dropped but at the same time making sure that we so not exceed the 5meg already allocated to this traffic?


How does one work out the normal and excess bursts? I've searched the web but can't find a definitive answer.

Thanks


mary


interface POS2/0

description *************

ip address x.x.x.x x.x.x.x

no ip redirects

no ip unreachables

no ip proxy-arp

rate-limit output access-group 109 5000000 4470 4470 conform-action transmit exceed-action drop

no ip mroute-cache

no cdp enable

!


access-list 109 permit ip host xx.xx.xx.xx any


ISP_1#sh int pos 2/0 rate-limit

Output

matches: access-group 109

params: 5000000 bps, 4470 limit, 4470 extended limit

conformed 15956424 packets, 11692M bytes; action: transmit

exceeded 747192 packets, 942248096 bytes; action: drop

last packet: 0ms ago, current burst: 0 bytes

last cleared 3d18h ago, conformed 286000 bps, exceeded 23000 bps


Correct Answer by Joseph W. Doherty about 8 years 1 month ago

If your IOS supports either shaping and/or rate-limiting, there's seldom need to perform both.


Generally, since shaping buffers bursts, it often drops less packets than rate-limiting, but actual impact depends on the traffic. (Sam makes a great point about shaping having possible additional delays not seen with rate-limiting.)


Whether you're doing shaping or rate-limiting, both will send at link speed, when they transmit. Assuming your ISP is policing your traffic to an agreed "bandwidth", ideally you would want to match their policing parameters to obtain the most possible bandwidth. This would be true regardless whether you rate-limit or shape.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
cisco_lad2004 Fri, 05/15/2009 - 03:20
User Badges:
  • Gold, 750 points or more

you could either increase your burst size gradually and test or if IOS allows it shape instead of rate limit.


with shaping you would buffer instead of dropping ...which in turns introduces delay. so if you have sensitive data dont shape.


HTH


Sam

maryodriscoll Fri, 05/15/2009 - 03:50
User Badges:

Okay, thanks. I do have 2 other ACL's also applied to the rate-limit output on this so I don't thiink I can shape/rate-limit at the same time.....I'll try your idea.

maryodriscoll Fri, 05/15/2009 - 04:01
User Badges:

One other question. My IOS accepted both shaping and rate-limiting - will it work though or is there anything I should look out for?

cisco_lad2004 Fri, 05/15/2009 - 05:16
User Badges:
  • Gold, 750 points or more

if you are trying it 1st time, then it needs to be tested and measured....even if cisco doc says it works. few QOS configs are bugged and few can cause issue...so test.

Correct Answer
Joseph W. Doherty Sat, 05/30/2009 - 11:01
User Badges:
  • Super Bronze, 10000 points or more

If your IOS supports either shaping and/or rate-limiting, there's seldom need to perform both.


Generally, since shaping buffers bursts, it often drops less packets than rate-limiting, but actual impact depends on the traffic. (Sam makes a great point about shaping having possible additional delays not seen with rate-limiting.)


Whether you're doing shaping or rate-limiting, both will send at link speed, when they transmit. Assuming your ISP is policing your traffic to an agreed "bandwidth", ideally you would want to match their policing parameters to obtain the most possible bandwidth. This would be true regardless whether you rate-limit or shape.

Actions

This Discussion