A query on GARP updates

[Sowmya Sridharan]

Hi All,

I am having a scenario wherein an IP address is transferred from one 
processor to another in case of a failure.
These two processors are in communication with a central server, and 
frequently send out GARPs to update their details.

Consider the processors X and Y which report to server Z.
Processor X had the IP, and sent out a GARP at 't' second. The server Z 
updated the ip and mac addresses of processor X.
Processor X rebooted immediately, and therefore the ip address got 
transferred to processor Y within 300-400 milliseconds.
Now processor Y sends out a GARP immediately within 't+1' second, and 
since the interval has not crossed 1 second threshold, this GARP is 
ignored by the server.
Hence there is a loss of traffic until the ARP cache is refreshed in the 
server, and the older entry is deleted, before the new request is 
considered.

This happens due to a condition specified in net/ipv4/arp.c

/* If several different ARP replies follows back-to-back, use the FIRST 
one. It is possible, if several proxy  agents are active.
    Taking the first reply prevents arp trashing and chooses the fastest 
router. 
 */
override = time_after(jiffies, n->updated + n->parms->locktime);    
==============> n->params->locktime being one second

/* Broadcast replies and request packets do not assert neighbour 
reachability.
 */
if (arp->ar_op != htons(ARPOP_REPLY) ||
    skb->pkt_type != PACKET_HOST)
        state = NUD_STALE;
neigh_update(n, sha, state, override ? NEIGH_UPDATE_F_OVERRIDE : 0);
neigh_release(n);

The above condition is for ignoring the arps from proxies, but in my case, 
the GARPs which is not from a proxy are also ignored.
I think this condition is breaking the functionality under the scenario I 
explained. Or is there any other reason for this condition, and I am 
missing it? 

P.S: I came across a similar post on the net, but there wasn't any 
solution provided :(

Regards,
Sowmya

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110330/9ca5a865/attachment.html