|
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.
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.
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.
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
-
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
