Check Point

Check Point and F5© BIG-IP© LTM© Alert of the Week: RX traffic drastically reduced post fail over, possible ARP issue

Last updated: September 15, 2025

Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.

The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog

Key Takeaways

The alert detects a failover event in a Check Point ClusterXL (and similarly F5 BIG-IP LTM) and compares traffic levels before and after the failover.
In the example, the newly active cluster member received 0 packets in roughly 3 minutes post-failover, versus 104,462 packets on the previously active node in a comparable pre-failover period.
This traffic discrepancy suggests that adjacent network devices may not have updated their Layer 2 information to recognize the new active cluster member.
The likely cause is MAC address changes associated with virtual IP ownership moving between cluster members during failover.
Although ClusterXL sends gratuitous ARP messages to update MAC-to-IP mappings, some network equipment may not correctly process these updates, requiring manual review and remediation (see Check Point SK50840).
The monitoring logic triggers the alert whenever post-failover traffic on the new active node is not remotely comparable to traffic seen on the previous active node.

ALERT concept. Business technology internet and networking concept - ALERT text on virtual screens

NOTE: The alert detailed below is given with a Check Point ClusterXL example, although F5 BIG-IP LTM is covered for this issue as well (see SOL7332).

This is a real life sample alert from indeni

Description:

A fail over was identified at Device time: Jul 18 03:02 2014 UTC, indeni time: Jul 18 03:02 2014 UTC. This device is now the active member of the cluster and in the period immediately following the fail over (3 minutes more or less) it received 0 packets compared to 104462 packets that were received by jcnj-fw2 (10.10.10.2) in a similar amount of time immediately BEFORE the fail over. This indicates the possibility that the surrounding network equipment may not be aware of the fail over on the layer 2 level.

Manual Remediation Steps:

It is possible this is caused by the fact that during a fail over the responsibility for the virtual IPs moves from one cluster member to the other and the MAC addresses change. ClusterXL issues gratuitous arps to deal with this but it may not work with your equipment. Please review SK50840 for more information.

How does this alert work?

indeni monitors the traffic passing through all members of an HA cluster. If it sees that post a failover the newly active member isn’t seeing remotely similar levels of traffic as the pre-failover active member did, the alert is triggered.

Interested in learning more? Download for free the official indeni guide to Preemptive Maintenance of Check Point Firewalls. Just fill out the form below:

[ninja_form id=5]

Unlock $120K+ in network ROI

Check Point and F5© BIG-IP© LTM© Alert of the Week: RX traffic drastically reduced post fail over, possible ARP issue

Related content

Agentic AI adoption in network observability propels NetOps teams

Stop the ticket bottleneck: Automate DNS, DHCP, and IPAM with Quick Service

Stay ahead of network issues with real-time metrics with BlueCat Integrity X

Adding business context to DDI with tagging in BlueCat Integrity X