I could see our pool monitor tcp_half_open is becoming down due to IPv4 address mismatch error? what is this error? This issue is intermittent.
After some time members are coming up.
May 06 08:28:20 localhost notice mcpd: 01070638:5: Pool /Data/ABC_8003 member /Data/10.10.10.10:8003 monitor status down. [ /Common/tcp_half_open: down; last error: /Common/tcp_half_open: IPv4 address mismatch @2019/05/06 08:28:20. ] [ was up for 24hrs:0min:6sec ]
May 06 08:43:38 localhost notice mcpd: 01070727:5: Pool /Data/ABC_8003 member /Data/10.10.10.10:8003 monitor status up. [ /Common/tcp_half_open: up ] [ was down for 0hr:15mins:18sec ]
This issue is only for monitor tcp_haf_open, not for any other monitor. Working fine with other monitors like tcp, http.
There is no any changes in F5 as well in environment.
This KB may help: https://support.f5.com/csp/article/K12829
-It is an older KB that is no longer maintained.
--I hope this helps! Have a great day!
To work around this issue, you can remove the TCP half open monitor from the pool or node and then add the monitor back. To do so, perform the following procedure:
Note: This workaround may need to be performed following each system reboot.
The root cause is difficult to answer, due to many unknown factors of your network topology. The BIGIP relies heavily upon Layer 2 and Layer 3 to be configured and stable, to maintain its stability. However, at times, a bigip services may run into an issue, which is explained in: https://support.f5.com/csp/article/K12829
As of A.D. 2020, the "tcp_half_open" monitor type is actually needed about as often as you need your vacuum-tube tester. Years ago, a few quirky server-side resources required this type of monitor, but no current software needs it, although it appears as a kind of dusty artifact in inherited configurations. Also, running many instances of "tcp_half_open" monitors also presents a surprisingly high computational load on the control plane. So the best thing to do is to change the monitors to be the simple "tcp" type.