Mailing List Archive

[lvs-users] IPv6 loadbalancer and source addr selection
Hi,

I want to set up a IPv6 load balancer in direct routing mode. So I configure a
IPv6 address an my loadbalancer and the same IPv6 addr on the lo interface of
the real servers.

No to the problem:
Since the IPv6 is the last IPv6 address configured on the interface in that
subnet the loadbalancer uses this IPv6 addr to communicate with the real
server. The real server answers to the IPv6 addr on the lo interface and to
communication is possible.

So no connection from the loadbalancer to the real server is possible.

I found a solution via the ip -6 addlabel (see RFC 6724). No I am wondering if
the is a more simle solution. Any hints? Thanks.

--
Mit freundlichen Grüßen,

Michael Schwartzkopff

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: [lvs-users] IPv6 loadbalancer and source addr selection [ In reply to ]
On 08.01.2014, Michael Schwartzkopff wrote:
> I want to set up a IPv6 load balancer in direct routing mode. So I configure a
> IPv6 address an my loadbalancer and the same IPv6 addr on the lo interface of
> the real servers.
>
> No to the problem:
> Since the IPv6 is the last IPv6 address configured on the interface in that
> subnet the loadbalancer uses this IPv6 addr to communicate with the real
> server. The real server answers to the IPv6 addr on the lo interface and to
> communication is possible.
>
> So no connection from the loadbalancer to the real server is possible.
>
> I found a solution via the ip -6 addlabel (see RFC 6724). No I am wondering if
> the is a more simle solution. Any hints? Thanks.

There are multiple ways to achieve this.

You noted the adress label, but according to RFC 3484, there are other ways with even higher preferences to influence the source address selection.


First of all, you may mark the services IP addresses as being deprecated:

/sbin/ip address change 2001:db8::1/64 dev eth0 preferred_lft 0

This IP address will be avoided in the default address selection, but still serve incoming requests. Intention of this "deprecated" flag is to still permit incoming traffic on dynamically allocated IPv6 addresses, who have been replaced by a different dynamically allocated IPv6 address. If you're running keepalived, simply upgrade to 1.2.9 and higher - these releases do automatically set the VRRP VIP address to be "deprecated" by default.

Secondary, you may also try to mark the host's IPv6 address as being a home address:

/sbin/ip address change 2001:db8::1/64 dev eth0 home

The intention of "home adress" is to properly support mobile IPv6; in mobile IPv6, your host receives an IPv6 address for its current network, but may also receive traffic via a tunneling setup from a tunneling endpoint on your home network via the "home address". According to RFC 3484, this setting should prefer your IP address when choosing an outgoing connection.

And not necessarily last: if your painpoint is only to implement checks from your realserver, you may also ask your checking utilities to bind to a specific (the hosts) IPv6 address when initiating outgoing connections. The default address selection only kicks in if the source address is undefined and to be determined by the system. In keepalived, this is is done via the "bindto" option in the check configuration.
I personally try to avoid this, as most manual debugging ("telnet realserver 80" ...) will still fall back to the default address selection and so give different results than the automated checks. However, there are cases where such specific binds may be important.




Best,
Anders
--
1&1 Internet AG Expert Systems Architect (IT Operations)

Amtsgericht Montabaur HRB 6484
Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann,
Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek,
Jan Oetjen, Christian Würst
Aufsichtsratsvorsitzender: Michael Scheeren

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
Re: [lvs-users] IPv6 loadbalancer and source addr selection [ In reply to ]
Anders Henke <anders.henke@1und1.de> writes:

> On 08.01.2014, Michael Schwartzkopff wrote:
>
>> I want to set up a IPv6 load balancer in direct routing mode. So I configure a
>> IPv6 address an my loadbalancer and the same IPv6 addr on the lo interface of
>> the real servers.
>>
>> No to the problem:
>> Since the IPv6 is the last IPv6 address configured on the interface in that
>> subnet the loadbalancer uses this IPv6 addr to communicate with the real
>> server. The real server answers to the IPv6 addr on the lo interface and to
>> communication is possible.
>>
>> So no connection from the loadbalancer to the real server is possible.
>>
>> I found a solution via the ip -6 addlabel (see RFC 6724). No I am wondering if
>> the is a more simle solution. Any hints? Thanks.
>
> There are multiple ways to achieve this. [...]

Besides the very insightful stuff I elided above, what about adding a
local route for the VIP instead of adding the address? Of course that
works only if the VIP traffic is routed to the address of your load
balancer (ie. you don't need neighbor discovery), but this way you can
handle full IPv6 subnets as well.
--
Regards,
Feri.

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users