Re: [LARTC] why shape incoming traffic

From: "Michael T. Babcock" <mbabcock@fibrespeed.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] why shape incoming traffic
Date: Fri, 01 Mar 2002 19:27:44 +0000	[thread overview]
Message-ID: <marc-lartc-101501092828076@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101494774514020@msgid-missing>

On Thu, Feb 28, 2002 at 05:53:15PM -0800, Don Cohen wrote:
> It doesn't seem very important to shape the incoming traffic that will
> be forwarded, since the same shaping can be done at output.

Obviously ...

> However, it does seem useful to be able to shape the incoming traffic 
> destined for the local machine.

... the only other option, besides rejection of course ;-)

> For example, suppose this machine is running a server that you want
> to limit to 10 connections/minute.  It seems reasonable to do this
> by limiting the rate at which syns are delivered to that server.
> That might be a lot easier than trying to modify the server.

I use application-level software for that (iplimit in conjunction with
tcpserver allows me to limit per-service connection rates on a per-source
basis).

> You might argue that doing it in the server would have the advantage
> of being able to make more intelligent decisions about which ones to
> accept and which to drop, but in fact the opposite could also be the
> case.  (I'm working on a project that provides an example.)

I agree with the Unix-way of doing things usually, not the emacs way --
don't build it into the program if it works just as well outside the
program; thus iplimit.  Programs that accept their own connections,
like Apache, can't use an external program of course (yet), so it would
make sense to build this in although I proxy my incoming connections
through a Squid service set up as an accelerator with bandwidth pools
turned on.

> What I find frustrating is that, as a firewall, I can already do this
> stuff for the servers (and clients) running on OTHER hosts, but I
> can't do it for those running on the local machine!

I've got around that in some situations by teaching myself to treat the
gateway/firewall box as a non-service box -- it runs nothing but the
firewalls, tunneling, forwarding and shaping.  This allows it to work as
desired (all traffic goes out one of the two interfaces; none goes
to the local host).
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/