A question about arping

[Sowmya Sridharan <sowmya.sridharan@xxxxxxx>]

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 were 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? 

Thanks,
Sowmya Sridharan
=====-----=====-----=====
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



--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html