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
