I am trying to limit/control our bandwidth connection to the Internet to 2Mbps. We are in the process of changing providers and are paying based on usage instead of a flat amount. We have a 3560 switch that has all of the users behind it and this is where we would like to implement some sort of bandwidth limitation. I am currently thinking of doing the following:
class-map match-any HTTPClass
match access-group 100
police 2097000 8000 exceed-action drop
access-list 100 permit tcp any any eq www
service-policy input HTTPPolicy
Does this look correct? Any other suggestions? We looked at CAR and rate-limit but this is not avaliable on a 3560
If you internet connection is out gigabitethernet 0/1, i would suggest applying the policy on the outbound direction rather than inbound
service-policy output HTTPPolicy
HTH, rate if it does
I thought about that, but as most Internet connectivity falls into the "asynchronous" style (more download than upload activity) I figured it would be more effective on the inbound as the majority of the HTTP traffic would be inbound.
Apply in both the directions if that suits you.
Even though an Inbound policy drops the packet, it would have already used the bandwidth on the link
True I did not look at it that way. If a user is trying to download a large file from the Internet and we limit the capacity in the 3560 the file is still going to come through the connection causing us to be charged for it and then it would be dropped at the 3560 due to the policy-map. The only way this would be effective would be in the outbound direction. I do not believe that there is a way to limit inbound as all of the devices that we are able to put restrictions on are located after the providers device that is determining our utilization/costs. Isn't that nifty. Thanks again for your input
The 3560 does not support egress policing via service policies, if you try to attach a policy to the 'output' of an interface you will get an error message. You can however limit the bandwidth with the interface command:
srr-queue bandwidth limit <10 - 90>
This does affect all traffic though so you should apply ingress policers to your access ports to classify (and police?) your traffic prior to it being sent to the egress interface.
If you really need to apply strict QoS for different traffic types then you should use a router (or maybe a Catalyst 6500 but this is likely to be far too expensive?)
You are correct! It does generate an error message when applied in the outbound. Well, inbound will not help because by the time it reaches our device then we will have already been charged for the access and outbound will not work because it is not allowed. Good thing this connection is just temporary. Sounds like the best solution is to just get a better connection with a flat rate and let the limitation of the connection do all the policing that it wants. This in conjunction with getting people to actually work instead of surfing the Internet for non work related activites. Thanks Again
If you shape or police outbound TCP ACKs, you can somewhat control inbound bandwidth utilization of TCP traffic.
The reason I note "somewhat" is you don't know exactly what's the size of the inbound packet and TCP senders will still burst as they open their send windows.
Effectively it won't meter traffic as exactly as a far side shaper or policer but it does work.
Do keep mind that you must shape or police ACKs to a much, much lower rate than the rate desired for the return traffic.
I agree and thats why you can do this better with products like riverbed, WAAS, Packeteer etc as these can intercept the TCP handshake and effectively do not allow anyone to use more than a certain bandwidth