lkml.org 
[lkml]   [2002]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: hidden interface (ARP) 2.4.20
Hello,

[Maybe we should discuss this in private, it doesn't have a lot to do
with kernel development anymore.]

> Because when you have to deal with thousands of session per second, NAT is
> really a pain in the ass. When you have to consider security, NAT is a pain

Not with a HW LB, and with a SW LB (LVS-NAT) you can very well sustain
20000 NAT'd load balanced connections with 5 minutes of stickyness
(persistency) with 1GB RAM and a PIII Tualatin with 512 kb L2 cache. I'm
not sure if you meant this when mentioning pain.
> too because it makes end to end tracking much more difficult when you deal with
> multiple proxy levels. And last but not least, there are protocols that don't

Security mustn't rely on the LB with such a high volume traffic service.
You need a carefully designed firewall framework. At least in the setups
I've been dealing with LBs (a couple dozen) this was the case. Load
balancing a service with multiple proxies doing NAT certainly imposes an
additional problem when doing proper end-to-end healthchecking, but is
nothing that couldn't be solved or would be extremely difficult.

> like NAT. Simply think about a farm of FTP servers. It's really easy to
> load-balance internet clients on it with redirection (call it as you like) using
> a hash algorithm. NAT would be more difficult.

I agree completely with this one. Don't get me wrong, I also most of the
time deploy a LB using the redirection method.

> I personnaly suggested and used both NAT and redirection at a big customer's
> site. NAT was there only to be compatible with broken systems that would never
> handle redirection right, in the event we would have to use them. But at the

HP/UX < 11i is such an example of horribly broken system. It can still
be solved with direct routing (redirection, triangulation) but you need
additional NICs.

> moment it's already the first source of architectural problems.

Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [from the cache]
©2003-2011 Jasper Spaans