|
Hi Joe,
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
> compatible.
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
following points):
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html#MTU
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
them.
> > 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.
Ok.
> > 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.
Great.
> > 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 :-)
Great :)
> good luck. Thanks for taking on the job.
Thank you very much!
Julius
--
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
|
