gratitous arps may be sent out too quickly for network device to process, which may result in stale ARP entries on the device.

Some upstream devices will start dropping gratuitous ARPs above a certain threshold/rate.

This issue only occurs with some network devices, and usually with a large config that has a large number of virtual addresses.

Thanks for your help! So what should I do if the gratitous arps was lost after a big-ip envent lost? K19910045: Forcing the BIG-IP system to resend gratuitous ARP requests Which way has least impact on business?

You need to configure your upstream devices to not drop gratuitous ARPs, or use Mac Masquerade so the gratuitous ARPs are not required.

You can also reduce the rate at which the BigIP issues gratuitous ARPs to match your devices - this may delay failover, however.

Just reissuing ARPs is unlikely to resolve the issue, as the upstream devices will continue to drop some of the ARPs, leading to an inconsistent ARP table.

Hello Zexiong,

I encountered a similar problem at a customer.

By default, the arp.gratuitousrate database variable is set to 0, which means that there is no limit to the number of gratuitous ARPs that the BIG-IP system can send out per second. If the arp.gratuitousrate database variable is set to values in the order of several thousands, the behavior is similar to 0 (unlimited).

So as evoked Blakely, you have to reduce the number of ratuitous ARPs that the BIG-IP system can send out per second.

I managed a client that had more than 800vs. and I also noticed that the gratuitus arp were retransmitted 3 times (2400 arp). So if had to reduce the rate of arp send by second to resolve my issue.

https://support.f5.com/csp/article/K11985

Regards