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

Rate-limiting on egress interface to ISP

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

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Re: Rate-limiting on egress interface to ISP

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.

5 REPLIES

Re: Rate-limiting on egress interface to ISP

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

Community Member

Re: Rate-limiting on egress interface to ISP

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.

Community Member

Re: Rate-limiting on egress interface to ISP

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

Re: Rate-limiting on egress interface to ISP

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.

Super Bronze

Re: Rate-limiting on egress interface to ISP

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.

998
Views
0
Helpful
5
Replies
CreatePlease to create content