On Fri, 11 Jan 2008, Simon Horman wrote:
But you do make some good points there, and I'm begining to think
that PREROUTING is correct.
Having LVS in LOCAL_IN was a reasonable idea at the time,
but then people came up with new things to do for LVS that
didn't work real well with the LOCAL_IN approach, eg
VIP-less directors. As well people quite reasonably expected
any iptables rule to work and they didn't.
Since the evolution of LVS has been helped by ideas from
people who weren't present for the original design, is it
possible to enumerate the reasons for/against
PREROUTING/FORWARD. At least then after we've made a
decision and then later a new idea breaks LVS, we can at
least look back to see if we should have seen it coming.
o Will either approach allow F5-SNAT? It would be nice to
have a scheme where a machine did not have to be
reconfigured to run as a realserver.
o Will it be possible for clients on realservers to be
clients of the LVS? (It would be nice to be able to stack
LVS calls to arbitary depth, but I can imagine it would be
easy to get an infinite loop if not setup properly).
Currently not being able to do this requires redesign of the
application(s) running on the realserver, which in any
setting where you must pay a programmer, or recertify the
application, will be too expensive and people will just go
buy a loadbalancer.
o Will iptables rules get the incoming packets before LVS on
the way in and after LVS on the way out? ie will you be able
to write arbitary iptables rules knowing that the incoming
packet has dst_addr:port and outgoing packet has
new_dst_addr:new_port? If LVS hooks PREROUTING, presumably
it will have to be after iptables. Presumably after LVS
hooks the packets they appear in POSTROUTING where you can
apply arbitary iptables rules to the packets?
o Will either approach work better with SSL accelerators?
People have to use these because they're cheaper than buying
a certificate for each realserver.
o Will either approach make it easier to code up an
active/active version of LVS?
o Just in case, is it possible to code up the FORWARD
version too in case someone thinks of a bright idea that we
haven't thought of?
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