|
Joseph Mack NA3T wrote:
> On Fri, 15 Sep 2006, Per Jessen wrote:
>
>>> o You took care of the arp problem, right?
>
> hold on - there's no arp problem with LVS-Tun, since there's
> no route directly from the client to the realservers.
That was also my first thought, but the docs on "the ARP problem" does
talk about both LVS-DR and LVS-TUN.
>>> o There's no rp_filter enabled on the RS?
>>
>> # cat /proc/sys/net/ipv4/conf/all/rp_filter
>> 1
>
> leave all of these at the default setttings (actually maybe
> not, the default setting for rp_filter for debian is wrong -
> see the HOWTO).
OK.
> Debugging LVS-Tun with realservers in some remote location
> is difficult. Can you setup 3 (or 4) boxes on a bench:
> client, director, and 1 (or 2) realserver and test that?
> You'll need to put a static entry in the arp table of the
> client for the VIP, so that the client doesn't send packets
> to the realserver directly.
Yep, I've got a test-setup pretty much like that - one director, 4 real
servers. What I don't have are multiple networks, I'd have to get hold
of some more kit to test that too.
The objective of this exercise (in case anyone is interested) is to run
one or more LVS's, with the ability to add new servers more or less
on-demand. All servers will be leased in remote datacentres, and I was
hoping to avoid having to put too many restrictions on the networking
side. (makes it easier to work with the datacentre people).
/Per Jessen, Zürich
|
