Re: Making IPVS work with IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 28 Mar 2008, Julius Volz wrote:

Hi LVS devs,

I'm currently interning at Google Zurich and we are very interested in porting IPVS to IPv6. Indeed, I will probably dedicate 60-70% of my time to that cause for the next 5 months to come.

wonderful. Thanks

1) It looks as though there is no current effort on the way to do this port, right?

correct.

2) Are there any serious technical or political roadblocks to this we are not seeing?

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.

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.

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.

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.

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.

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 :-)

So I've been looking at the code for a couple of days now and some parts I understand well, others I don't get at all, but I hope to change that soon ;)

good luck. Thanks for taking on the job.

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

[Index of Archives]     [Linux Filesystem Devel]     [Linux NFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [X.Org]

  Powered by Linux