Re: Making IPVS work with IPv6

To: "Joseph Mack NA3T" <jmack@xxxxxxxx>
Subject: Re: Making IPVS work with IPv6
Cc: lvs-devel@xxxxxxxxxxxxxxx
From: "Julius Volz" <juliusv@xxxxxxxxxx>
Date: Mon, 31 Mar 2008 12:51:57 +0200
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):

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

Great :)

>  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

<Prev in Thread] Current Thread [Next in Thread>