[Pacemaker] Pacemaker Digest, Vol 45, Issue 55

[Alan Robertson]

On 8/30/2011 6:39 AM, leopoldo tosi wrote:
>> But it gets even more interesting. I did a tcpdump on eth0
>> interface
>> (the interface the IPaddr2 resource IP is on) the box
>> running the
>> resources and I get the following when resources start up
>> (presumably
>> triggered by the box trying to connect for the status
>> check):
>>     01:12:21.423330 arp who-has 192.168.2.21
>> (Broadcast) tell 192.168.2.21
>>     01:12:22.428523 arp who-has 192.168.2.21
>> (Broadcast) tell 192.168.2.21
>>     01:12:23.429342 arp who-has 192.168.2.21
>> (Broadcast) tell 192.168.2.21
>> Notice as my box seems to be having a slight identity
>> crisis
>> (192.168.2.21 is the IPaddr2 resource)
>>

As an FYI:

Someone else already probably said this - but this particular sequence 
is the result of taking over an presumably-live IP address from one 
machine to another.

One RFC says you can force an update of the ARP cache by sending a 
(broadcast) ARP reply, and that works for most routers/switches.  
However, another RFC says you can force ARP caches to be updated by 
sending an ARP _request_.  This latter behavior works on the other 
routers/switches.  So we do both.  We ask "who has our IP address?" and 
send it from our IP address.  Then we send a _broadcast_ reply to our 
own request.  This is all instigated by the IPaddr and IPaddr2 resource 
agents.  The normal ARP protocol code is not involved in this particular 
sequence.

It looks pretty silly - but it works very effectively.

     -- Alan Robertson
         alanr at unix.sh