--- On Tue, 10/26/10, Andrew Beverley <andy@xxxxxxxxxxx> wrote:
> From: Andrew Beverley <andy@xxxxxxxxxxx>
> Subject: Re: Limiting user's bandwidth
> To: "Landy Landy" <landysaccount@xxxxxxxxx>
> Date: Tuesday, October 26, 2010, 6:21 PM
> On Tue, 2010-10-26 at 14:49 -0700,
> Landy Landy wrote:
> > What I'm really trying to accomplish is basically
> assign a certain
> > amount of bw for a client for example:
> 512k/128k. If I would like to
> > change that later on either increase or decrease
> speed I would like to
> > do so.
>
> Hmmm, in which case you probably have no option but to have
> a leaf for
> each IP (unless this is only for web browsing in which case
> I think
> Squid does what you want).
>
> > I have a php script that rewrites all the tc
> rules from a
> > database so, everytime a client is added it
> rewrites it again with the
> > new clients ip address. So, each client will
> have a whatever amount of
> > bw without sharing it with anybody else.
> >
> > This is what the script writes:
> >
> > ## Client's name
> > $iptables -t mangle -A POSTROUTING -d 172.16.100.36 -j
> MARK --set-mark 1003
> > $iptables -t mangle -A POSTROUTING -d 172.16.100.36 -j
> RETURN
> > $tc class add dev eth1 parent
> 2:311 classid 2:1003 htb rate 563kbit ceil
> 676kbit prio 4
> > $tc filter add dev eth1 parent 2:0
> protocol ip prio 4 handle 1003 fw classid
> 2:1003
>
> I'm no expert, but I would remove the prio parameter. I
> think this is
> matching the prio value of a packet - probably not what you
> want. I
> would also change the "classid" to "flowid".
The reason for the prio is becuase I'm prioritizing other traffic. I want DNS, SSH, ICMP, and VOIP to have a higher priority than the rest.
Havent tried the flowid instead of the classid, don't know
if it makes a big of a difference but, I will give it a try
and see how traffic behaves.
>
> > $tc qdisc add dev eth1 parent
> 2:1003 handle 801: sfq perturb 2
> >
> > ######################
> > ## Client's name
> > $iptables -t mangle -A POSTROUTING -s 172.16.100.36 -j
> MARK --set-mark 1002
> > $iptables -t mangle -A POSTROUTING -s 172.16.100.36 -j
> RETURN
> > $tc class add dev eth0 parent
> 1:310 classid 1:1002 htb rate 141kbit ceil
> 169kbit prio 4
> > $tc filter add dev eth0 parent 1:0
> protocol ip prio 4 handle 1002 fw classid
> 1:1002
> > $tc qdisc add dev eth0 parent
> 1:1002 handle 800: sfq perturb 2
> >
> > Also, let's say I would like to sell bandwidth this
> would help out a lot.
> >
> > I don't know if I'm making more complicated than what
> it is but, so far
> > I only have the download working. I have a
> couple of clients that
> > upload a lot of stuff and don't want them to own
> the upload bw. If it
> > wasnt' for these I wouldn't mind to leave it as
> it is now but, I would
> > like a solution.
>
> Yes, it does seem to be more complicated than it needs to
> be. Why not
> just allow them to use the bandwidth that is available
> (fairly) and
> charge them per amount of data transferred?
>
> > I would like to add the p2p rules from your script
> later on.
> >
>
> You can just add these as a few extra rules to MARK the
> packets
> accordingly. However... if you're limiting per client IP
> address then
> they are largely irrelevant, as the user will just fill up
> their own
> leaf with P2P data.
You are correct, adding your p2p rules will make the kernel
work harder. Just realized I stablished this control because
of p2p. That was my first reason and later just decided to
give each user the same amount of bw.
Charging per usage bw will not fit us. Our clients rather
have a real amount of bw than limit themselves to a cap of
traffic.
Thanks again.
> > FYI:
> > The captive portal I would like to create is also for
> this application for a WISP LAN.
>
> Shouldn't be a problem; just do the access control stuff in
> PREROUTING
> before it's hit any of the traffic control rules.
>
> Andy
>
>
>
