Last Modified: Mar 12, 2025
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 17.0.0, 17.0.0.1, 17.0.0.2, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.5.0
Opened: Sep 12, 2024 Severity: 4-Minor
After rebooting the BIG-IP system, the 'Last Error' field in the /var/log/ltm log for a TCP monitor shows as empty (null) following the first occurrence of the monitor's down status. mcpd[6893]: 01070638:5: Pool /Common/http_pool member /Common/192.168.10.71:80 monitor status down. [ /Common/my_tcp_monitor: down; last error: ] [ was up for 0hr:0min:41sec ] And If pool member goes back to 'up' and then 'down' again, 'last error:' string is not empty, but the 'last error" string is not the most recent failure reason following. mcpd[8820]: 01070638:5: Pool /Common/http_pool member /Common/10.2.116.207:80 monitor status down. [ /Common/myhttpmon: down; last error: /Common/myhttpmon: Response Code: 200 (OK) @2024/12/09 00:14:23. ] [ was up for 0hr:0min:32sec ]
Users may not be able to determine the cause of monitor failures immediately after a system reboot, and pool member goes back to 'up' and then 'down' again. as the 'Last Error' field does not provide the necessary diagnostic information
The issue occurs when the monitor status of system is up and rebooted and during the first occurrence of a monitor's down status following the reboot, and pool member goes back to 'up' and then 'down' again.
None
None