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.

Thanks,

John

Joseph,

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

Thanks,

John

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,

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.

Thanks,

John

John

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

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

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.

Jon

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

Thanks!

John

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.

PS:

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

Joseph,

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.

Thanks!

John

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.

Okay,

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 10.20.1.0 0.0.0.255

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 10.20.1.0 0.0.0.255 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?

Thanks,

John

John

"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 10.20.1.0 0.0.0.255"

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.

Jon