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
al...@unix.sh
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
