Every person who uses a Linux firewall/gw for their home network needs to know this.
Let me guess a problem you have.. Whenever someone is uploading on the network, TCP sessions seem to lose interactivity. The biggest display of this is ssh connections. Whenever someone is uploading, ssh connections all have that delay thing going on. You start off feeling like that machine in New York is right around the corner, even though you are in San Francisco. Start uploading something, BAM.. All of a sudden that unix box feels like its on the moon as you find yourself waiting 3 seconds to see your typing come back to you.
If you have a cable modem or DSL line, and a Linux box doing NAT, you likely are dealing with this problem.
Its your DSL/Cable modem's fault. Its got this really big buffer in it, and whoever fills it up wins. That's whoever is uploading, running BitTorrent, et cetra. In office environments, its almost constant.
There is an easy fix for this.. So easy, that you will spent more time reading this, and trying to understand it, then you will actually performing it.
] TBF is very precise, network- and processor friendly. It should
] be your first choice if you simply want to slow an interface down!
And there are a number of reasons you might want to slow down an interface. One very basic and important thing to remember about traffic control: You cannot control the way in which you receive data, but you can control the way you send it.
In the case of your home network, you don't want your firewall sending anything to the DSL/Cable device at a rate faster then it can pass on. Its a stupid device. A stupid device with a very big buffer in it. Its just going to let that buffer fill and send everything fifo (First In First Out). It does not know that you don't care about the BitTorrent as much as the SSH traffic. Its just going to let the buffer fill and send it in order.
Enter the Token Bucker Filter:
] # tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
] Change 220kbit to your uplink's *actual* speed, minus a few percent. If
] you have a really fast modem, raise 'burst' a bit.
And of course, substitute ppp0 for whatever your external interface is. Unless you are using PPPoE, its likely eth0 or eth1.
This way, once Linux starts to send packets to the DSL/Cable modem faster then it can send, Linux overlimits and starts dropping packets rather then telling them to all get in line and wait for their turn.. This results is TCP connections where interactivity matters (like ssh) no longer having issues. All your outbound traffic is still fighting for the same bandwidth, but whoever is speaking the loudest does not drown everyone else out.
For the record, this is the command I currently have in my security gateway's rc.local:
tc qdisc add dev eth3 root tbf rate 250kbit latency 50ms burst 1540
My max upstream seems to be about 260kbit and my external interface is eth3, because my gw has four ethernet interfaces.
This post links through to the appropriate page in the most excellent Linux Advanced Routing & Traffic Control HOWTO. It explains everything I have here, and more.
How to make BitTorrent (or other uploading applications) stop crushing SSH sessions