On Sat, 13 Sep 2008, Julius Volz wrote:
I'm wondering about how hard it would be to add SNAT
support to IPVS (that is, the director rewriting packets
from the client to backends to appear to be from the VIP
and some randomly allocated port).
when we've discussed it before, the packets will appear to
come from the DIP, a private IP (or whatever IP the servers
were using for their default route before they were put into
This would allow us to have remote real servers with
more importantly, people who are bound by serious IT rules
setup by managers, can duplicate their (real) servers only
with a change in RIP on each server and can keep the default
I realize that Jason Stubb's PRE/POSTROUTING patches would
also make this possible, but they seemed risky and we
haven't heard of them in a long time.
Jason just sent me his current patch this week. You could
ask him for it directly. Apparently it's little/no different
to the patch he posted at
(hope I'm paraphrasing Horms correctly here...)
Horms would be happy to have this in the main release if it
could be invoked as an option.
Also, having this option directly integrated into the rest
of the IPVS NAT code might make it easier to use: just add
another flag on the ipvsadm command line when you want
SNAT for an LVS/NAT backend.
sounds great to me.
From talking to Horms, LVS-NAT (and possibly LVS-DR) sends
the packets to the realservers via
which bypasses the OUTPUT chain. It would seem to me that if
you instead injected the packets into the OUTPUT chain, then
normal iptables rules could handle the SNAT to the
realservers. It might be slower that rewriting the packets
yourself, but for a first attempt, I think people will be so
happy to have the functionality that they won't quibble
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