public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roberto Nibali <ratz@drugphish.ch>
To: Willy Tarreau <willy@w.ods.org>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: hidden interface (ARP) 2.4.20
Date: Sun, 08 Dec 2002 00:30:23 +0100	[thread overview]
Message-ID: <3DF2848F.2010900@drugphish.ch> (raw)
In-Reply-To: 20021206060135.GC21070@alpha.home.local

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


  parent reply	other threads:[~2002-12-07 23:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 20:53 hidden interface (ARP) 2.4.20 Bingner Sam J Contractor PACAF CSS/SCHE
2002-12-05 21:42 ` David S. Miller
2002-12-05 22:03   ` Phil Oester
2002-12-05 22:50     ` Roberto Nibali
2002-12-05 23:48       ` Phil Oester
2002-12-05 23:59         ` Roberto Nibali
2002-12-06  6:01           ` Willy Tarreau
2002-12-06 17:52             ` Stephan von Krawczynski
2002-12-07 23:30             ` Roberto Nibali [this message]
2002-12-08 16:03               ` Stephan von Krawczynski
2002-12-08 17:01                 ` Willy Tarreau
2002-12-09 11:08                   ` Stephan von Krawczynski
2002-12-10  9:42                     ` Gilad Ben-Yossef
2002-12-10 10:40                     ` Roberto Nibali
2002-12-10 13:09                       ` hidden interface (ARP) 2.4.20 / network performance Stephan von Krawczynski
2002-12-10 18:11                         ` Roberto Nibali
2002-12-10 23:29                         ` Willy TARREAU
2002-12-10  1:22           ` hidden interface (ARP) 2.4.20 Bill Davidsen
2002-12-10 10:40             ` Roberto Nibali
2002-12-10 14:47               ` Bill Davidsen
2002-12-10 18:15                 ` Roberto Nibali
2002-12-11 16:15                   ` Bill Davidsen
2002-12-12  1:33                     ` Bernd Eckenfels
2002-12-05 22:18   ` Martin Josefsson
  -- strict thread matches above, loose matches on Subject: below --
2002-12-05 23:57 Bingner Sam J Contractor PACAF CSS/SCHE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DF2848F.2010900@drugphish.ch \
    --to=ratz@drugphish.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@w.ods.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox