Home Server Traffic Shaping

Index.

15-Apr-2012: Initial release.
10-Aug-2012: Add reference to the script's origin.
07-Jan-2013: Adjusted for Slackware
23-Mar-2015: Removed invalid link.

Introduction.

To prevent slow response when using the Internet when your Internet connection is heavily in use, you need to use some form of bandwidth management. Luckily Linux can do that but it’s a complicated story. We cannot do much about that data that is coming to our system, but we can manage the data that is being sent to the Internet. If you do this you will see that your Internet connection behaves much better under heavy load.

The tool to manipulate the traffic is tc which is in the iproute2 package. The tc program can only manipulate the queue with IP packets to transmit and change the priority order. The packets itself must be marked by the applications that sent them, or with iptables that inspects the packets and sets the right classify values.

In our Home Server project a new package is created, net-shaper that handles the tc commands.The rest will be done using the Firewall Builder that generates the necessary iptables rules.

The script.

I created a very firewall Slackbuild package that has an init script for the firewall, but also an init scrip and configuration file for the traffic shaper. The init script can be activated by making it executable just like any other init script. You only need to setup traffic shaping on the machine that runs your Internet connection, in our Home Server examples this is the virtual gateway machine. You need to configure /etc/rc.d/rc.shaper.conf to match your Internet connection speed and interface. On one of my systems this looks like this:

root@gw02:~# cat /etc/rc.d/rc.shaper.conf
# Configuration for traffic shaper
#
# Devices to control outgoing bandwidth, syntax device:uplimit:downlimit
# eth0:1024:10240 means limit eth0 to 1 Mbit up- and 10 Mbit downstream
# eth1:20240:20240 means limit eth1 to 20 Mbit up and down.
# Multiple devices are allowed:
#
# DEVS="eth0:1024:10240 ppp0:1280:20480"
#
# For ADSL/Cable, set uplink value at about 90% for best results.

DEVS="wan0:928:12800"

root@gw02:~#

Currently the download setting does nothing. The traffic shaper script divides the traffic into the following htb classes:

  • 1:10 rate 1/12 uplink speed, priority 0
  • 1:20 rate 4/12 uplink speed, priority 1
  • 1:30 rate 3/12 uplink speed, priority 2
  • 1:40 rate 2/12 uplink speed, priority 3
  • 1:50 rate 1/12 uplink speed, priority 4
  • 1:60 rate 1/12 uplink speed, priority 5

The uplink speeds are the minimum guaranteed speeds. If there is only traffic on the link in class 1:60 it gets the full speed, but it can get as low as 1/12 of the available uplink speed. You can now use a iptables rule to mark traffic with classify like this:

iptables -t mangle -A POSTROUTING -o eth1 -p tcp --dport 80 -j CLASSIFY \
   --set-class 1:50

This example above marks all TCP traffic to port 80 (Web) into htb class 1:50. The example below marks VoIP traffic generated by Asterisk:

iptables -t mangle -A POSTROUTING -o eth1 -m dscp --dscp-class cs3 \
   -j CLASSIFY --set-class 1:20

The example firewall for the gateway shows the types of traffic that is set in the different classes. It is like this:

  • 1:10 All TCP handshakes like SYN, RST etc. ICMP (limited). This is top priority.
  • 1:20 VoIP SIP and Audio, interactive SSH. This is normal high priority and guaranteed 25% of the available bandwidth.
  • 1:30 VoIP Video, external mail and web clients. DNS.
  • 1:40 Unknown UDP traffic.
  • 1:50 Bulk traffic like file transfers.
  • 1:60 Everything that is not classified.. Lowest priority.

There is one thing to know because we only have a IPv4 connection to the Internet, and via that connection IPv6 traffic goes travels in a tunnel to our IPv6 tunnel broker. So we have two protocols going via one link and one of the protocols is hidden in a tunnel. We can’t just classify IPv4 and IPv6 traffic and hope that all goes well. Instead, only IPv4 traffic must be classified. The IPv6 traffic is classified in a very simple way, we just look at UDP packets from or to port 5072 (the tunnel packets) and see how large these packets are. Small packets are assumed to be interactive traffic en large packets must be bulk traffic. Doing it this way makes the rate calculations correct and the connection will not be overloaded. But if you have a real IPv4 and IPv6 link, then you must also classify the IPv6 packets. A new aiccu package is being developed, in that new package you can mark IPv6 packets, and that mark will be transferred to the IPv6 tunnel packet.

Links.

Here are some links with more information about this subject.

Download.

See the download page for the script and configuration files.