Rate Limit ACL vs Service Policy.

In my QoS studies it hit me... Why would I want to use a rate-limit ACL anymore, since I can create a service-policy to do the same thing. I've used rate-limit ACLs on a few occasions but it recently only hit I could essentially do the same thing by assigning a % of the bandwidth to a particular class-map and instead of using the service-policy for "QoS" reasons I'd be using it for rate-limiting essentially.

So do I appear to be jumping the gun on this one? I really can't think of reason to use a rate-limiting ACL anymore..

Find more posts tagged with

Comments

cisco_trooper

Forsaken made a great point in this thread -> http://www.techexams.net/forums/off-topic/72118-access-list-question.html

Forsaken_GA

SteveO86 wrote: »

In my QoS studies it hit me... Why would I want to use a rate-limit ACL anymore, since I can create a service-policy to do the same thing. I've used rate-limit ACLs on a few occasions but it recently only hit I could essentially do the same thing by assigning a % of the bandwidth to a particular class-map and instead of using the service-policy for "QoS" reasons I'd be using it for rate-limiting essentially.

So do I appear to be jumping the gun on this one? I really can't think of reason to use a rate-limiting ACL anymore..

rate limiting is basically the old style of policing. You'd use it when you want to limit traffic under *all* conditions. Your policy maps won't be worth spit if your link isn't saturated, which will often be the case if you've got a speed mismatch (especially common on WAN links) between the line rate and the physical interface.

If all you need to do is rate limit by an ACL, doing it that way is usually quicker than setting up a policer via the MQC, but it's basically pick your poison, either way will work.

SteveO86

Forsaken_GA wrote: »

Is the WAN link actually 100 megs up to the provider? It's a FastEthernet interface, so if the link up to the provider is limited to something like 20 megs, then a policy map isn't going to work - the QoS bandwidth reservations don't kick in until there's saturation on the link. If you try and setup a CBWFQ policy on a 100 meg interface that's being rate limited on the far end to something less, you're going to find your policy has no effect.

If I specified the interface bandwidth command to the appropriate level wouldn't the service-policy/CBWFQ work according the bandwidth I specified at the interface level though?

Edit:
Ok I gotcha now.. The rate-limit ACL is always applied where-as the service-policy will be in effect when the link is over-utilized.. Gotcha Thanks!

Forsaken_GA

SteveO86 wrote: »

If I specified the interface bandwidth command to the appropriate level wouldn't the service-policy CBWFQ work according the bandwidth I specified at the interface level though?

A wonderful question!

I'm not going to answer it

And it's not because I'm being a dick, this is one thing you really should delve into yourself.

I suggest you do a whole lot of research into what the interface bandwidth command actually does, as well as the ramifications of changing it to something other than the actual link speed on the interface.

SteveO86

Off the top of my head it should effect QoS decisions.. Routing protocol metrics (such as EIGRP uses Bandwidth and Delay by default)..

Hmm, off to Cisco.com I go to see what I'm missing..