All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Joseph Mack NA3T <jmack@wm7d.net>
Cc: LVS Devel <lvs-devel@vger.kernel.org>,
	Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Subject: Re: [PATCH] Runtime interception method switch
Date: Fri, 18 Jan 2008 17:58:54 +0900	[thread overview]
Message-ID: <20080118085852.GC10957@verge.net.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0801160651530.313@wm7d.net>

On Wed, Jan 16, 2008 at 07:09:26AM -0800, Joseph Mack NA3T wrote:
> On Wed, 16 Jan 2008, Simon Horman wrote:
>
>> For starters could we clarify that the patch in question is the 
>> following one by Janusz Krzysztofik?
>
> I see Janusz has replied to this.

Yes I see. I'll take a look over the code a bit more.
But if he says its working then that is certainly a plus.

For the record, I am in favour of this change.

> I had assumed that if Raphael could output the packets to the right spot 
> (before POSTROUTING on the inbound direction?) that iptables could handle 
> the NAT'ing and no extra ipvs code would be neccessary.
>
> What I didn't know was the original reason the packets were output to a 
> place where iptables couldn't manipulate them. Was this for speed? to get 
> ipvs to work at all? If for speed, the director has always been limited 
> by wirespeed, not by anything in ipvs, so any increase in latency through 
> ipvs may not be seen.

I don't know the answer to that. But I guess speed. And you are right,
speed has never been much of a problem. Flexibilty on the other hand
and in particular interaction with contrack has always been problematic.

>> Also can I clarify that the aim is to be able to SNAT LVS-DR
>> connections
>
> I didn't realise Janusz was SNAT'ing LVS-DR.
>
>> (and if possible LVS-NAT and LVS-TUN)?
>> Or is the aim to add a new method, LVS-FULL-NAT?
>
> What the users want is to be able to put unmodified servers behind a 
> director - they can't even change the default gw. The only thing they can 
> change is the RIP. So the servers would have to be realservers behind an 
> LVS-NAT director which is outputting packets with src_addr=DIP, ie the  
> realservers see connect requests only from the DIP. I'd assumed the 
> director would be running a new version of standard LVS-NAT, with 
> iptables doing the SNAT in POSTROUTING.

Sorry to be picky. It seems to me that Janusz does achive the goal in
mind, in a fairly simple way. I will review ASAP.

-- 
Horms

  reply	other threads:[~2008-01-18  8:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13 15:12 [PATCH] Runtime interception method switch Raphael Vallazza
2008-01-13 17:59 ` Joseph Mack NA3T
2008-01-14  8:39   ` Raphael Vallazza
2008-01-14  9:42     ` Joseph Mack NA3T
2008-01-15  8:25       ` Simon Horman
2008-01-15 13:13         ` Joseph Mack NA3T
2008-01-16  7:50           ` Simon Horman
2008-01-16 11:16             ` Janusz Krzysztofik
2008-01-16 11:28               ` Raphael Vallazza
2008-01-18  8:52                 ` Simon Horman
2008-01-16 15:09             ` Joseph Mack NA3T
2008-01-18  8:58               ` Simon Horman [this message]
2008-01-18 13:12                 ` Joseph Mack NA3T
2008-01-15  8:20 ` Simon Horman

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=20080118085852.GC10957@verge.net.au \
    --to=horms@verge.net.au \
    --cc=jkrzyszt@tis.icnet.pl \
    --cc=jmack@wm7d.net \
    --cc=lvs-devel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.