On Mon, 2009-06-01 at 10:17 +0800, Shaun Chong wrote:
> I *think* I've addressed the ARP problem previously. If I didn't fix it, the
> whole LVS-DR wouldn't work in the first place, right?
No. The ARP problem manifests itself in a number of ways which can be
distilled as follows:
1. The realservers come up with the VIP bound to a dummy/loopback
2. The director comes up with the VIP bound to an ethernet interface
3. The upstream router sends an ARP request for the VIP:
ARP who-has $VIP
4. *Ideally* the director replies:
ARP $VIP is at $director_mac_address
However this isn't always the case, and a race condition occurs where
all hosts receiving the ARP request respond, and the first response
making it back to the upstream router is the one that the router then
sends traffic to.
If that's the director, all is fine and dandy.
If that's a realserver, then all requests will bypass the director and
will be handled by that realserver directly. This is why you see no
traffic on the director - there is no traffic.
How long this event takes to occur is dependent entirely on local
network conditions and the type(s) of servers involved. For some it
never occurs, for others it occurs instantaneously, for most it occurs
some unpredictable time after the system is brought up.
The docs you're using, although one way of doing things, are not
necessarily "the right way". You should try looking through the HOWTO or
searching this list's archive to find the common method, which is to use
the right sysctls to "hide" the dummy/loopback interfaces and prevent
the kernel from answering ARP requests for them.
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users