Last Modified: Jan 20, 2023
Affected Product:
See more info
BIG-IP TMOS
Known Affected Versions:
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.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, 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, 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
Opened: Mar 29, 2022
Severity: 2-Critical
You may observe LTM monitors are malfunctioning on your system. For instance, you may notice some probes are not sent out on the network, and some monitored objects are showing the wrong status.
LTM monitoring is impacted.
-- The bigd daemon consists of multiple processes (which you can determine by running "ps aux | grep bigd"). -- One or more of the processes (but not all of them) becomes disrupted for some reason, and stops serving heartbeats to the sod daemon. Under these conditions, sod will not take any fail-safe action and the affected bigd processes will continue running impaired, potentially indefinitely.
If you have determined, or if you suspect, this issue is present on your system, you can resolve it by killing all bigd processes using the following command: pgrep -f 'bigd\.[0-9]+' | xargs kill -9 However, this does not prevent the issue from manifesting again in the future if the cause for bigd's disruption occurs again. Monitoring may become further disrupted as bigd restarts, and a failover may occur depending on your specific configuration.
None
