The chosen answer is incorrect/incomplete. I faced a similar issue, the chosen answer gave some help, but not enough.
First, the following command is not really needed.
tc qdisc del dev eth0 root
It will 'delete' the root qdisc, but inmediately gets substituted by a pfifo_fast one (so you don't lose connectivity).
The second command:
tc qdisc add dev eth0 root handle 1: prio
Will substitute the pfifo_fast qdisc with the prio one. By default, the prio queue has 3 bands (0, 1, 2) each managed by one class (1:1, 1:2 and 1:3).
The packets will be sent to one of those bands using the TOS field of the IP package. This configuration is shown when you execute:
tc qdisc ls
looking at the 'priomap' values.
Then, you add a netem qdisc:
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms
With this command you delay all traffic going to the 1:1 band (until the filter is in place).
But there are two caveats:
- Your traffic can have a different TOS value and then being sent to another band.
- The prio qdisc can be configured so the traffic goes to another band.
The following solved my issue to not be affected by the netem while the filter is not applied. Instead of the above steps, I did:
tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
This will send all traffic by default to the band 1:3.
Then, I added the rule to delay traffic:
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 100ms 10ms
This creates the qdisc in the band 0, but since all traffic goes to band 3, it didn't affect me.
Afterwards, I added the filter:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Now with the filter, only the chosen IP/port will be affected, since we redirect the chosen traffic to the band 0.
All the other traffic continues unaffected since it continues to flow to band 3.
I wouldn't call it "traffic shaping" with a time resolution of one month... You do not want to impose any restrictions before this hard limit is reached? I think you need to watch the traffic and disable the account when the limit is reached (or activate traffic shaping then, making the connection quite slow).
You may add rules (without target) for each of the connections (after configuring static addresses as mentioned before) in order to see the amount of traffic from and to this user. Every hour or so you can call a script / program which reads this amount of data, adds it to the user's traffic log, resets the counter (iptables --zero), sum up the traffic log and take the appropriate action if the user's limit turnes out to be reached.
Best Answer
You can use tc to shape bandwidth like so
This class will shape certain addresses to a certain speed. We also need to setup a filter so that any packets marked as such go through this rule
tc class add dev eth0 parent 1:1 classid 1:5 htb rate 256kbps ceil 256kbps prio 1
tc filter add dev eth0 parent 1:0 prio 1 handle 5 fw flowid 1:5
Once that class is setup, you need to setup iptables to mark the specific packets you want to shape.
Next, create the mangle table that's needed.
iptables -t mangle -N shaper-out
iptables -t mangle -N shaper-in
iptables -t mangle -I PREROUTING -i eth0 -j shaper-in
iptables -t mangle -I POSTROUTING -o eth0 -j shaper-out
Next setup the marks that we need to shape certain IP addresses. mark 5 is the one that is shaped to 256.
iptables -t mangle -A shaper-out -s 10.0.0.5 -j MARK --set-mark 5
iptables -t mangle -A shaper-in -d 10.0.0.5 -j MARK --set-mark 5
That should shape 10.0.0.5 to 256kbps.
Reference (my blog) - http://sirlagz.net/2013/01/27/how-to-turn-the-raspberry-pi-into-a-shaping-wifi-router/