|
I think I found the explanation.
when the server H connects to VIP, the director forwards it to a RS.
the RS doesn't have H in its arp cache, and so it attempts to send an
ARP request. this ARP-request uses the IP which it will be using in the
reply packet, which is the destination IP of the original TCP connect,
in other words the VIP.
on the real server, we block all outbound ARP requests with a source
address of VIP using arptables. this is the way it has to be, since a
client receiving an ARP request MUST update its ARP table regardless of
the ARP operation. it's not enough to block outgoing replies, outgoing
requests will also poison caches. if we didn't block the ARP, all
subsequent communication between H and RS would sidestep the director.
the workaround is to make sure that the ARP cache on RS is populated
with entries for all servers on the LAN which need to talk to it. this
can be accomplished with periodic pings, since the ping packet (and
hence the ARP packer) will use the real server's service address, not
the VIP. the default ARP cache is quite generous, so you don't have to
refresh it too often (except to compensate for hardware changes). from
arp(7):
gc_thresh1
The minimum number of entries to keep in the ARP cache. The
garbage collector will not run if there are fewer than this num-
ber of entries in the cache. Defaults to 128.
--
Kjetil T.
|
