Re: [squid-users] Limiting user's bandwidth

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 25 Oct 2010 18:34:51 +1300

On 25/10/10 03:22, Landy Landy wrote:
> Hello everyone.
>
> A while back I posted here that I was trying to control our user's
> bandwidth with iproute. I know it can be done with squid but, didn't
> want squid to do more than block some domains and do its caching
> which does pretty well. I have a script to control bw and assign each
> user 512kbps/256kbps. When I have squid running the control gets
> bypassed.
>
> I was marking packets on the FORWARD chain which caused to the bypass
> since the pages are served from the gw by squid instead of just doing
> the FORWARD. Now, I did some thinking, and changed the chain marking
> the packet to look like this:
>
> $iptables -t mangle -A POSTROUTING -d 172.16.250.1 -j MARK --set-mark
> 1053 $iptables -t mangle -A POSTROUTING -d 172.16.250.1 -j RETURN
>
> This controls the download bandwidth the way I want it. Works well.
> Now, for the upload speed I guess I'm having the same problem as
> before. The upload speed does not get controlled. I applied this
> chain:
>
> $iptables -t mangle -A POSTROUTING -s 172.16.250.1 -j MARK --set-mark
> 1054 $iptables -t mangle -A POSTROUTING -s 172.16.250.1 -j RETURN
>
> and the user can upload at full speed.
>
> Also tried PREROUTING and nothing.
>
> I need to control upload since I have some users uploading videos,
> mp3, and other stuff that consume most of the upload bw.
>
> Does anyone has an idea how can I control the upload speed?

Marking by itself does nothing but set a number on each packets meta
data. You need other software which handles the marks and delays packets
based on them. "tc" is one such.

As you have notice packets which go to Squid are not FORWARDed by the
OS. They are received as INPUT to Squid, and sometimes as OUTPUT from
the Squid user and process.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.8
   Beta testers wanted for 3.2.0.2
Received on Mon Oct 25 2010 - 05:34:56 MDT

This archive was generated by hypermail 2.2.0 : Mon Oct 25 2010 - 12:00:02 MDT