|
Hello,
On Sat, 27 Apr 2002, Torsten Buslei wrote:
> Did I understand LVS-DR correct?
>
> The VIP on the director is the only one who answers to a arp-request.
> So, if a client want's to connect to the LVS, a arp-request to the VIP
> is send, which the director answers.
> Then, the director looks up the ipvsadm-rules and directs the
> tcp-request to a realserver. (again over MAC's, I think it's not
> importent here.)
> When the request arrives at a specific realserver, an answer is
> generated and send back to the client directly. The source-address of
> the tcp-packets is the VIP (non-arping address on the realserver), but
> the source-address of the IP-packets (MAC-layer) is the MAC-address of
> the sending device (ethernet-adapter of the realserver).
Absolutely correct
> That would mean, that the client has two different
> IP-MAC-addresses-pairs in its arp-table for the VIP. But it is only
> allowed to save one. Which one is it, the first (which means the
> MAC-address of the director) or the last (which means the MAC-address
> of a realserver)?
This is wrong, I don't know for IP stack that learns
the link layer info from IP traffic. It uses ARP for this.
IOW, it is not good to update the ARP tables for each received
IP packet.
> I think this question is importent for a nicely balenced cluster,
> because if the last possibility is true (MAC-address of the realserver
> in arp-table of the client), the next request will be directly send to
> the realserver without a scheduling of the director.
>
> In my tests with Linux-Boxes and solving the arp-problem with a second
> NIC, I had the described problems. (connection to realserver without
> scheduling by director), if you can realy speak of a problem ...
Your problem is that in Linux 2.2+ the second-NIC solution
does not solve the ARP problem. The "client" learns via ARP the
real server's MAC and this is not a desired behavior for IP clusters.
> Thanks for comments,
>
> Torsten
Regards
--
Julian Anastasov <ja@xxxxxx>
|
