|
Troy Hakala <troy@xxxxxxxxxxxxxx> wrote:
> In an LVS-NAT setup, on a rare occassion, the ARP cache of one of the real
> servers gets the wrong MAC address for the director, I assume after a
> re-ARP. It gets the MAC of eth0 instead of eth1. It's easy to fix with an
> arp -s, but I'd like to understand why this happens.
Taking a wild guess, I would say that eth1 is handling a connection
that has the VIP as the local address. And during the course of
that connection, the local arp cache expires. The director
sends an arp-request to refresh its cache. However, the
source address of the ARP requests is the VIP, as it is a connection
to the VIP that caused the ARP requests. ARP requests actually
act as ARP announcements. And thus the MAC of eth0 is advertised
as the MAC of the VIP.
Just a guess. If its correct, then this is exactly the
problem that the arp_announce proc entry is designed to address.
Or alternatively you can use arptables.
This is the second half of the ARP problem that has to be solved
when doing LVS-DR, and I have some limited explanation of it
at http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html#real-servers
Just ignore the bits that aren't about either arp_announce or
/sbin/arptables -A OUT -j mangle...
It could also be that for some completely perverse reason
eth1 is receiving an ARP request for the VIP. If that case
you are really in the same boat as using LVS-DR.
--
Horms
|
