Re: [LARTC] why shape incoming traffic

[don-lartc@isis.cs3-inc.com (Don Cohen)]

 > From: "Michael T. Babcock" <mbabcock@fibrespeed.net>

 > > 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 ...
Bert didn't think it was so obvious.
(I don't understand yet what squid is doing.)

 > > 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).
There are benefits to doing this sort of thing at the firewall.
For instance, it works for servers running different OS's.
And once you have the control working for your inside network it
seems unreasonable to have to change the implementation in order
to move a server to the firewall machine.

(Another advantage of doing it at the firewall is that you can then
control the aggregate of traffic to different hosts.  But the ability
to shape traffic to the local host would not be enough to retain that
advantage when moving a server to the firewall.)

 > > 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.
I'm not sure what the emacs reference was all about.  I'm not
suggesting building the limit into the server, just the opposite.
(My solution also works with apache.) 

 > > 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).
That's a solution dictated by the necessity imposed by our inability 
to shape traffic to the local host.  Clearly there are times when 
you'd rather run something on the firewall.  There are also times
when you have to - programs that are supposed to communicate with the
outside world to control the firewall.  It's just as important (maybe 
more) to shape the traffic to those programs as to others.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/