|The traffic shaper is a simple device, but it gives fairly precise control over your system's outgoing network traffic.|
Until recently there has been no ability to throttle bandwidth usage in the stable Linux kernel series. The 2.1 development kernels have had the traffic shaper for a while, but it's only with 2.0.36 that this driver has been added to the stable kernel (thanks to a backporting effort by Alan Cox). The traffic shaper is a simple device, but it gives fairly precise control over your system's outgoing network traffic (incoming traffic is rather harder to control, and is not affected directly by the traffic shaper).
To use the traffic shaper facility, you'll need (1) a suitably configured 2.0.36 or 2.1 kernel, and (2) the "shapecfg" utility. Happily for the author, Red Hat 5.2 includes both right out of the box, though little associated documentation is included. In fact, about the only shaper documentation in existence is (1) the source, and (2) this file that comes with the kernel source. Fortunately, the shaper is a fairly simple thing to configure.
The first step is to configure your networking normally. The traffic shaper creates a pseudo networking device that is used by the system, but it relies on the underlying ethernet (or whatever) interface to actually carry the traffic. Once you set up the shaper interface, do not shut down the underlying physical interface, or unpleasant things will happen. This restriction would appear to make the traffic shaper unsuited for non-dedicated connections, such as PPP links.
The traffic shaper must be built as a kernel module. If you want the module to autoload with kerneld, you will need to add a line like:
alias shaper0 shaperto /etc/conf.modules. Either that or just use insmod at boot time to load the shaper module. The insmod command, like those that follow, can be placed in /etc/rc.d/rc.local (on Red Hat systems) to have it executed at boot time.
The next step is to attach the shaper device to the physical interface, and to set the speed limit. That is done with a pair of commands like:
/sbin/shapecfg attach shaper0 eth0 /sbin/shapecfg speed shaper0 64000The first line hooks the pseudo-interface "shaper0" onto the real interface "eth0" - the first ethernet interface. The second sets the maximum speed to 64 Kbits per second. According to the documentation, the workable range is from 9600 to 256,000 bits per second. I have verified that higher speeds work pretty well (i.e. the metering is accurate), but the traffic is bursty.
Then you need to configure the shaper0 interface for networking, using the usual sort of ifconfig and route commands.
ifconfig shaper0 host netmask mask broadcast bcast up route add -net net netmask mask dev shaper0Of course, all of the parameters in italics must be replaced with suitable values for your network. The host/address, mask, and broadcast parameters need to match those of the underlying physical interface.
At this point, assuming you have left your system's normal networking setup in place, you likely have two different routes for your local network. Things seem to work that way, but it's inelegant. You may want to delete the route pointing directly at the physical interface. You may also want to change the default route out of your system, assuming you set one statically, so that traffic for the world goes through the shaper:
route delete default eth0 route add default gw gateway shaper0That's all it takes. An easy, if imprecise, test to verify that the shaper is working for you is to simply FTP a large file from another machine. FTP kindly prints out the bandwidth it gets; in the absence of other interference on the net you should get something very close to the value you gave in the shapecfg command.
Advanced use of the traffic shaper could involve the use of IP alias interfaces and fancy routes to impose limits on traffic to specific sites. There is also a patch by Mike McLagan on ftp.linux.org which allows setting point to point routes which allows even more fine per-host control of bandwidth use with the traffic shaper.
(Thanks to Alan Cox for commenting on a draft of this page).