Bug ID 874877: The bigd monitor reports misleading error messages

Last Modified: Jun 13, 2024

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 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, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2, 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, 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

Opened: Jan 30, 2020

Severity: 3-Major

Symptoms

When a recv string is used with an HTTP/HTTP2/HTTPS/TCP monitor, the HTTP status code is collected and in the event of failure, the most recent value (from before the failure) is retrieved and used as part of the log output. This can result in a message that is misleading.

Impact

Generates a misleading log messages, difficulty in identifying the actual cause of the monitor failure. This occurs because the system stores the 'last error' string for these monitors. This can be misleading, especially when a receive string is used. Following is an example: -- A BIG-IP system is monitoring an HTTP server that is returning proper data (i.e., matching the receive string). -- The HTTP server goes down. Now the BIG-IP system will have a last error string of 'No successful responses received before deadline' or 'Unable to connect'. -- The HTTP server goes back up and works for a while. -- For some reason, the HTTP server's responses no longer match the receive string. In this case, a message is logged on the BIG-IP system: notice mcpd[6060]: 01070638:5: Pool /Common/http member /Common/n.n.n.n:n monitor status down. [ /Common/my_http_monitor: down; last error: /Common/my_http_monitor: Unable to connect @2020/01/09 04:18:20. ] [ was up for 4hr:18mins:46sec ] The 'Unable to connect' last error reason is not correct: the BIG-IP system can connect to the HTTP server and gets responses back, but they do not match the received string.

Conditions

- The BIG-IP system configured to monitor an HTTP/HTTP2 server. - The BIG-IP system configured to monitor an HTTPS/TCP monitor.

Workaround

None

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips