QoS doesn't work for capping speed

Unanswered Question
Mar 4th, 2009


This morning I created an acl that included my local subnet: I created a class-map to match this access list, and then I created a policy that referenced this class-map.

class-map match-all RESTRICTED

match access-group 20

policy-map SPEED


shape average 8000

Standard IP access list 20

10 permit, wildcard bits (127 matches)

This was applied outbound on the public interface. I started to download a large file, and my speeds were very high. I then went back into the policy and added a class-default with the same values. The policy map started shaping the traffic back.

Shouldn't I be able to scale back according to an acl, and if so, why did this not take effect unless it was under class default? The acl was applied to the class-map, so I'm not sure why it wasn't matching on that.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
adamclarkuk_2 Wed, 03/04/2009 - 05:20

Sorry, misread your post.

How did you attach the ACL to class-default, I don't think this is possible ( I could be wrong).

It looks like your ACL is wrong as well.

John Blakley Wed, 03/04/2009 - 08:53

How is my acl wrong? I want to shape anything going out of that subnet.

I didn't attach the acl to class-default. I wanted to see if my shaping was working at all, so I just shaped the class-default class and that was it. The class-default worked with the same parameters as I had for my class RESTRICTED, but the class RESTRICTED wouldn't work with them.



Joseph W. Doherty Wed, 03/04/2009 - 09:36

Without seeing your actual config and/or stats, can't say for sure what your issue might be.

John Blakley Wed, 03/04/2009 - 09:38


My config is posted. What else would you like, and I can get it. It's very simple because I'm trying to see qos in effect.

Oh, the policy is applied outbound on the public interface:

service-policy output SPEED



william.mccall Wed, 03/04/2009 - 10:08

Two things:

1) You're shaping outbound. This will only affect the speed of the outbound traffic.

2) To control the rate of INBOUND traffic, you need to use a police and apply it inbound on your WAN int

Jon Marshall Wed, 03/04/2009 - 10:29


When you say public interface is this an internet connection then ?

When you used class-default did you use an acl. It sounds like you didn't.

You should be able to shape according to an acl but it sounds as if you are not matching the correct IP's ie. have they been natted by then ?

Could you post output of

sh policy-map interface


John Blakley Wed, 03/04/2009 - 11:26


I do use nat on my router. The acl wasn't applied to class-default. I applied the shaping command to the class RESTRICTED in the policy map, but that didn't restrict it. I applied the same shape command to class-default, and that did restrict it.

I've always been under the impression that you can shape traffic outbound, and then you police inbound. I didn't have another policy map inbound on my public interface to police the return traffic. Is this necessary, and if so, why? I figured that the router was keeping the nat translations, and it should know that the return traffic had originated on the inside. If that's the case, then why does the class-default work?

I'll have to post the show command later when I get home tonight. This is on my router at the house.



Jon Marshall Wed, 03/04/2009 - 11:44


Have a look at this link about the order of operation with NAT -


Basically NAT happens before queueing/shaping so i think what is happening is that your acl is referencing the wrong address ie. it should be the Natted address and not the 10.x.x.x address.

Only way to know for sure is to retest with the NAT ip address in your acl.


John Blakley Wed, 03/04/2009 - 11:46

Hmmm, I'll try this tonight and let you know something tomorrow.



Joseph W. Doherty Wed, 03/04/2009 - 11:51

I was going to ask whether you're were using NAT, since you mentioned a "public" interface. Instead this is one reason why I asked to see the config. (Helps avoid the 20 questions game.) In your reponse to me, you write you've posted it, but besides a couple of config lines in your OP, having trouble finding it.

If you're using NAT and you're matching, outbound, on a 10.x source IP, is the source IP still 10.x? If not, it would explain why your not matching within your defined class yet class-default works.


Yes you can shape outbound and police inbound, but a downsteam policer will not insure an upsteam link isn't congested.

John Blakley Wed, 03/04/2009 - 11:56


I didn't take into consideration that nat could be making a difference. I don't have access to the config at the moment, so I only posted what the qos config would have been.

I'm going to try to change my source address and see if that works, and I'll let you know tomorrow.



Joseph W. Doherty Wed, 03/04/2009 - 12:06

If NAT is the issue, you can "color" your traffic with a DSCP tag upon router ingress and use the tag for selecting it for outbound.

John Blakley Thu, 03/05/2009 - 06:42


I played around with it this morning, and I noticed a couple of things.

First, policing works on the public interface applied inbound. I'm assuming that I could police per protocol/port via acl, but I haven't tried this.

Second, shaping did work, but I had to put the policy on the inside interface as output, and I had to change the acl to:

permit ip any

This did shape the traffic back drastically.

I didn't try to apply it as input to the interface with the acl as:

permit ip any

Would that have the same effect?

I also didn't get a chance to get the config while it was applied, but it was definitely matching packets this time.

As far as policing, shouldn't I be able to police certain type of traffic coming into the public interface? The way that I did it would've affected all outbound traffic coming back in, and this may not be necessarily what I would want in a real scenario.

Also, if I have nat disabled (like I do in my branches), should my original config have worked?



Jon Marshall Thu, 03/05/2009 - 07:00


"Second, shaping did work, but I had to put the policy on the inside interface as output, and I had to change the acl to:

permit ip any"

Okay but bear in mind this is not shaping the traffic from your router upstream it is shaping it once it gets back to your router which is quite different.

Did you try to change the acl to match your Natted address or did you not carry out that test ?

"Also, if I have nat disabled (like I do in my branches), should my original config have worked?" - well i think it would.


John Blakley Thu, 03/05/2009 - 07:37


I did try output with the acl matching my public IP, and I don't think this worked. The acl was like:

permit ip host 99.x.x.x.x any

I can't tell you if I changed this around, but I think I did.

I'm having a hard time figuring out where to put the policy though. When do you put the policy on the public interface, and when do you apply it to the private side??

Thanks Jon!


Jon Marshall Thu, 03/05/2009 - 11:56


Depends on what you are trying to achieve. You generally shape/police as you go from a faster to a lower speed medium. An example that i have used is where we have connected to a Service providers MPLS network and they have provisioned a 100Mb connection to us but we only need 30Mb so we shape on the interface that connects to their PE device.



This Discussion