Thanks for the great feedback!
On Fri, Mar 28, 2008, Joseph Mack NA3T wrote:
> There is an effort underway to move ipvs() from the LOCAL_IN
> chain, where it currently sits for historical reasons, to a
> better place. A better place is either PREROUTING or
> FORWARD. Both hooks look OK at the moment. It is possible
> that the location will be decided at run time. This work is
> being done by Janusz, who is on this mailing list, but AFAIK
> it's not in the kernel and hasn't had testing by selected
> users. You should coordinate with him so that your codes are
Ok, good to know, I will do that!
> There is a problem with PMTU discovery when using LVS-Tun
> (described in the HOWTO), which is currently handled (I
> think) by iptables and an mss option. Part of the problem is
> that the Linux networking stack doesn't do PMTU correctly.
> At least be prepared for this problem. I don't know how easy
> it would be to fix.
Thanks for the warning, I guess you are talking about this (and the
Does this have any special implications in the IPv6 case? The problem
looks pretty complicated and no one seems to completely understand it
;) I will keep it in mind for later though.
> We don't have enough people using UDP to know how LVS should
> handle UDP. There are problems with UDP (described in the
> HOWTO). People are trying to setup SIP on LVS. With all the
> ports involved in the protocol, I don't expect it will be
> easy. I expect the only solution will be a module on the
> director (like the ftp helper) that understands the SIP
> protocol. It seems that multiport protocols are going to
> become more common as coders try to get through ISPs who
> think it's their business to throttle the internet.
Again, interesting info. Is there a specific relation to IPv6 though?
> ipvs has an uneasy relationship with netfilter. ipvs
> bypasses netfilter for speed. However in doing so, iptables
> no longer works as users would reasonably expect (at least
> for LVS-NAT). With cpus getting faster, relative to networks
> (I think that's true), it may not hurt if ipvs is a little
> slower, for more compatibility with netfilter. However the
> speed of ipvs is a well regarded feature. *BSD has
> loadbalancing but it's slow compared to ipvs, so we wouldn't
> want to drop too much speed.
Aha, interesting. Could you explain a bit more for a newbie in what
ways IPVS "bypasses" netfilter? Other than that IPVS is basically a
Netfilter extension, it is still not really clear to me how other
Netfilter features are affected when using IPVS in combination with
> > 3) Currently, IPVS lives under .../net/ipv4/ipvs in the
> > kernel, but much of the code is not IPv4-specific.
> I expect this is all historical, from when ipvs was based on
> masquerading code, rather than netfilter.
> > Any ideas on how to best refactor that common code to make
> > it usable for both IPv4 or IPv6?
> If you write it and are happy with it, we'll take your
> scheme :-). Horms has been doing all the work on LVS for the
> last couple of years, knows the code and has thought a
> lot about where LVS should and shouldn't go. I'm sure he'll
> have ideas on what's best.
> > 4) How could this work be best split up into manageable
> > chunks that could either be worked on serially or in
> > parallel (by multiple developers)?
> There hasn't been much developement on ipvs recently. The
> original developer Wensong hasn't been active for a while
> and Horms took over. Horms is the one who submits the new
> code to the kernel. But Horms has been busy doing other
> things and in the meantime ipvs is not getting a lot of
> attention. So you'll be it if you take on the ipv6 job.
Wow, ok. Again, I don't have any experience with kernel coding, but I
will learn as much as I can!
> > 5) Who else would be interested in parts of this effort or
> > just in helping out when questions come up?
> Anyone on this list will be happy to listen to anything you
> have to say :-)
> good luck. Thanks for taking on the job.
Thank you very much!
Google Switzerland GmbH
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