[nSLUG] upstream bandwidth with iptables

Jamie Fifield jamie at fifield.ca
Mon Jun 2 12:43:25 ADT 2003

Redhat has some some basic qos stuff built in already.  Check out
/etc/sysconfig/cbq.  There not a lot of documentation, and it's
intended for throttling an entire real interface.

spanky:/etc/sysconfig/cbq# tc qdisc list
qdisc tbf 8048: dev eth1 rate 250Kbit burst 10Kb lat 152.6ms
qdisc cbq 11: dev eth1 rate 10Mbit (bounded,isolated) prio no-transmit

spanky:/etc/sysconfig/cbq# cat cbq-9000.ftp

So that config file says, rate limit my eth1 to 900Kbit, except if
it's between 7am and 7pm, in which case it should be 250Kbit.  (I've
got to run "/etc/rc.d/init.d/cbq timecheck" at 7:01 to reset it though).  

Pretty easy once you know how.  It can get a lot more complicated to
do sophisticated stuff.

On Mon, Jun 02, 2003 at 10:58:38AM -0300, Dop Ganger wrote:
> You don't want iptables, you want qos instead. I use this myself to limit
> the amount of bandwidth being used on production servers for
> non-production services. The general implementation is:
> Create a cbq for your nic, set to 10 meg
> Create a bunch of sub-cbqs chained off the first cbq, I use them as
> follows:
> Low bandwidth high priority (eg, ssh)
> Low bandwidth low priority (eg, SMTP for non-MX servers)
> High bandwidth high priority (eg, http on a web server)
> High bandwidth low priority (eg, NNTP)
> Other traffic
> For each cbq assign the amount of traffic you want to use for each queue.
> For example, a machine that's a webserver on a T1 will get 1.4 meg of the
> pipe (you don't want to assign the max amount of traffic possible!). Once
> you have the cbqs set up, you'll need to use a filter to direct traffic
> into the correct queue - I use sfq, Stochastic Fair Queueing, which works
> pretty well.
> Now,
> in your case, you want to either set a bunch of ports into the high
> bandwidth low priority queue (and give that cbq, say, 5% of your outbound
> pipe), or you can quantify all your traffic use and then set the other
> traffic cbq to catch the remainder of the traffic. Which one you use
> depends on whether you know the ports that are going to be used; if you
> know them all, you can set them into the high bandwidth low priority
> queue, otherwise (if, for example, the p2p app picks ports at random to
> get around people trying to pull this sort of trick) you're going to have
> to rely on the default queue.
> Now, in the past few days someone's come out with a new "layer 7" which
> looks to do exactly what you want - filter by protocol used (eg, gnutella,
> kazaa, http) instead of simply by port. I haven't had a chance to try it
> myself yet, but it looks promising - see http://l7-filter.sourceforge.net/
> for details.
> A couple of final points to note. QoS in Linux is designed pretty much
> solely to shape outbound traffic that is exiting the NIC. However, if
> you're using this on a Linux router, you *have* two interfaces running
> traffic exiting the NIC; that going to the outside world, and that going
> to the inside world. Using a Linux router, you can shape traffic in both
> directions *very* precisely. Secondly, you can get a fairly noticeable
> performance boost by prioritising ACK packets; this puts ACKs at the
> "front of the queue", meaning a lower round trip time for the ACK packet
> which means the remote end can throw more data at you more quickly.
> If anyone's interested, I have a couple of QoS scripts I can clean up and
> release; one's for single interface machines and one's for dual interface
> machines in a firewalling config.
> Cheers... Dop.
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug

Jamie Fifield
<jamie at fifield.ca>

More information about the nSLUG mailing list