LTM - Monitor with "arping" relies on ARP-Cache

Hello,

I'm trying to implement the arping monitor without success.

I've created a bash file as follows:

#!/bin/bash
IP=$1
INTERFACE="VLAN434"  # Use the VLAN name which connect with the endpoint nodes.
 
arping -c 1 -I $INTERFACE $IP > /dev/null 2>&1
if [ $? -eq 0 ]; then
    echo "UP"
    exit 0
else
    echo "DOWN"
    exit 1
fi

I've tested this command locally an work fine, but once that I've import the file via "System  ››  File Management : External Monitor Program File List" it appears under monitor section but I cannot apply to a current defined Node..

Once that I create the monitor also I don't know if I've created correctly the monitor, see attached image.

Please, can someone help me with the exact configuration?

Thanks in advance.

hi dude
could u pls share url with arping health-monitoring u use?
thanks

I will post an answer from F5-Support.

The behavior is "as designed"

[...]

Nonetheless after doing some additional information please be noted that Linux

traffic not destined to the management network is picked up and forwarded by

TMM which maintains its own ARP table. As a result there are two arp tables

the TMM one and the Linux host one.

The first time that IP address is being resolved to a MAC address (i.e. when

TMM doesn't know about that IP yet), TMM will send a broadcast ARP request to

the network.

Once TMM becomes aware of where that IP address lives, and while it considers

its entry fresh, TMM will not ask the network again, even if the Linux host

(e.g. arping) is trying to resolve it again.

This is behavior is per design but may lead to unexpected result such as

marking pool member up based on TMM's cached response rather than based on

actual ARP request send out towards the destination server.

Maintaining both ARP tables with the external monitor script (for instance

clearing ARP tables) is generally also not recommended (as tmsh commands such

as clearing arp table is not scalable might consume cause to consume more

CPU/memory resources and may lead to unexpected results for instance when next

instance of the script is executed before end of previous tmsh execution).

As alternative for external monitoring using arping tool - please consider

applying ICMP_gateway monitor (you can strict ICMP traffic in network to

specific IP's only - that belongs to BIgIP's non-floating self-ip and

destination pool members).

[...]