[128567] in North American Network Operators' Group
Re: IPv6 Server Load Balancing - DSR
daemon@ATHENA.MIT.EDU (Leland Vandervort)
Thu Aug 12 13:34:29 2010
From: Leland Vandervort <leland@taranta.discpro.org>
In-Reply-To: <AANLkTikLkYP93jUvVPQ7-_htc=q35BgLT0quTEwgrQJ4@mail.gmail.com>
Date: Thu, 12 Aug 2010 19:34:18 +0200
To: William Cooper <wcooper02@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Well, Frankly our "culture" is very much open source, so if we can find =
something along those lines, then it would be preferred. (Hence looking =
at OpenSolaris and ILB). -- having said that, we do have both F5 and =
Foundry kit here, but it's all pre-IPv6 so doesn't have the support =
built in. Not really looking to replace what is in existence already =
for IPv4 with something new to do both, so really that reinforces the =
open-source avenue really.
I think the biggest problem is really the DSR aspect for IPv6, since the =
OS/ILB solution works perfectly in NAT mode, and DSR works perfectly =
with IPv4 on this solution. So either I'm missing something critical on =
the "real" server configuration, or ILB's implementation of DSR for IPv6 =
doesn't really work. The "virtual" IP is bound to loopback on the real =
servers, exactly the same was as for IPv4. So other than something =
quirky going on with ND, or simply ILB not correctly rewriting the L2 =
frame, or there's something else more sinister afoot that I'm unable to =
put my finger on.
Back to the drawing board... :)
Thanks,
Leland
On 12 Aug 2010, at 19:23, William Cooper wrote:
> I know there have been quite a few responses for both h/w and s/w
> solutions, it's not clear
> which your preference is of the two. I know there are various h/w
> vendors that offer a s/w
> solution (mostly in conjunction with some form of virtualization
> environment), such as A10.
>=20
> I've been testing A10 for a while now, and they seem very keen on
> developing parity between
> v4 and v6 feature sets / performance.
>=20
> DSR is more or less a L2 trick that plays on some inherent weaknesses
> and constraints
> that are present with v4 local address resolution (don't mean to
> preach to the chior); I think
> most responses here have touched on the primary challenges of DSR with
> v6. I'll be exploring
> DSR with dual stack v4/6 in the near future, I'll let you know how
> that turns out.
>=20
> Hmm... not sure how this helped.
>=20
> Regards,
>=20
> -Tony
>=20
> On Thu, Aug 12, 2010 at 12:40 PM, Leland Vandervort
> <leland@taranta.discpro.org> wrote:
>> Hi Owen,
>>=20
>> The DSR address is indeed on a loopback in our case.
>>=20
>> lo Link encap:Local Loopback
>> inet6 addr: ::1/128 Scope:Host
>> inet6 addr: xxxx:xxxx:x:xxxx::xx/128 Scope:Global
>>=20
>>=20
>>=20
>> The mystery continues...
>>=20
>>=20
>> Leland
>>=20
>>=20
>> On 12 Aug 2010, at 18:28, Owen DeLong wrote:
>>=20
>>>=20
>>> On Aug 12, 2010, at 6:19 AM, Xavier Beaudouin wrote:
>>>=20
>>>> Hi Leland,
>>>>=20
>>>> Le 12 ao=FBt 2010 =E0 15:11, Leland Vandervort a =E9crit :
>>>>=20
>>>>> OpenSolaris ILB is open solution ;)
>>>>>=20
>>>>> but yea, that's what we've started looking at -- hence LVM / =
HAProxy as well.. (though LVM is IPv4 only, and HAProxy is NAT only for =
IPv6)
>>>>>=20
>>>>> does relayd support UDP as well as TCP or is it layer7 only like =
HAProxy ?
>>>>=20
>>>> It does everything... :) L2 -> L7...
>>>>=20
>>>>> In the case of ILB, I'm not convinced that it's a problem with the =
LB itself, but rather the idiosyncrasies of ND in IPv6 that is causing =
the problem.. but I may be wrong... at any rate, something's amiss ...
>>>>=20
>>>> Maybe on some setup you should desactivate ND...
>>>>=20
>>>> Xavier
>>>=20
>>> If you're putting the DSR address on an interface other than =
loopback, you probably need to turn of DAD on the interface with the DSR =
address otherwise DAD
>>> will shut down that address on the interface when it sees other =
servers with the same address. Sometimes it will shut down all but one, =
sometimes it will
>>> shut down all.
>>>=20
>>>=20
>>> Owen
>>=20
>>=20
>>=20
