<br><font size=2 face="sans-serif">Hi All,</font>
<br>
<br><font size=2 face="sans-serif">I am having a scenario wherein an IP
address is transferred from one processor to another in case of a failure.</font>
<br><font size=2 face="sans-serif">These two processors are in communication
with a central server, and frequently send out GARPs to update their details.</font>
<br>
<br><font size=2 face="sans-serif">Consider the processors X and Y which
report to server Z.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Processor X rebooted immediately, and
therefore the ip address got transferred to processor Y within 300-400
milliseconds.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">This happens due to a condition specified
in net/ipv4/arp.c</font>
<br>
<br><font size=2 face="sans-serif">/* If several different ARP replies
follows back-to-back, use the FIRST one. It is possible, if several proxy
agents are active.</font>
<br><font size=2 face="sans-serif"> Taking the first reply
prevents arp trashing and chooses the fastest router. </font>
<br><font size=2 face="sans-serif"> */</font>
<br><font size=2 face="sans-serif">override = time_after(jiffies, n->updated
+ n->parms->locktime);
==============> n->params->locktime being one second</font>
<br>
<br><font size=2 face="sans-serif">/* Broadcast replies and request packets
do not assert neighbour reachability.</font>
<br><font size=2 face="sans-serif"> */</font>
<br><font size=2 face="sans-serif">if (arp->ar_op != htons(ARPOP_REPLY)
||</font>
<br><font size=2 face="sans-serif"> skb->pkt_type != PACKET_HOST)</font>
<br><font size=2 face="sans-serif"> state =
NUD_STALE;</font>
<br><font size=2 face="sans-serif">neigh_update(n, sha, state, override
? NEIGH_UPDATE_F_OVERRIDE : 0);</font>
<br><font size=2 face="sans-serif">neigh_release(n);</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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? </font>
<br>
<br><font size=2 face="sans-serif">P.S: I came across a similar post on
the net, but there wasn't any solution provided :(</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Sowmya</font>
<br>
<br><pre style="white-space:normal">=====-----=====-----=====<br>Notice: The information contained in this e-mail<br>message and/or attachments to it may contain <br>confidential or privileged information. If you are <br>not the intended recipient, any dissemination, use, <br>review, distribution, printing or copying of the <br>information contained in this e-mail message <br>and/or attachments to it are strictly prohibited. If <br>you have received this communication in error, <br>please notify us by reply e-mail or telephone and <br>immediately and permanently delete the message <br>and any attachments. Thank you<br><br><br></pre>