|
In article <Pine.LNX.4.61.0605180926140.2301@xxxxxxxx> you wrote:
> [-- text/plain, encoding quoted-printable, charset: X-UNKNOWN, 30 lines --]
>
> On Thu, 18 May 2006, [iso-8859-1] Herv? Eychenne wrote:
>
>> Why is that so? Why couldn't LVS proceed as netfilter NAT
>> does? (that is, not require that the IP address is really
>> defined on the gateway)
>
>
> LVS was originally based on masquerading code. Then when
> netfilter came along, LVS was rewritten for netfilter, but
> the fit wasn't really good. It was originally hoped that LVS
> would just be a netfilter module, but for reasons I don't
> understand, it couldn't be done. As well some of netfilter
> was written in a way that disabled some of the features of
> LVS (transparent proxy). There's a fair bit of code that
> wasn't fixed up and got forgotten about, when it didn't
> impact anyone. Ken Brownfield just found one of them. The
> problem is that all of LVS is being done by less than a
> handfull of people working in their spare time.
>
> So it may be quite possible to have LVS do what you expect
> here and no-one has done it. Are you up for fixing it?
I'm pretty sure that it is possible two. As far as I can work out there
are two main issues that need to be addressed.
1) LVS needs to move from netfilter's LOCAL_IN chain to the FORWARDING
chain. I did this once before and it seemed to be very easy and work
well, though I am sure there are a few corner cases in there that
need some love.
2) The linux-director needs to respond to ARP requests for the VIP.
This is likely as simple as injecting an entry into the arp table,
in much the same way that is done for proxy-arp (often used with ppp).
--
Horms
H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/
|
