Last Modified: Oct 06, 2020
See more info
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 18.104.22.168, 22.214.171.124, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1
Opened: Jun 01, 2017
Related AskF5 Article: K69205908
A pool member configured through an FQDN node and which has multiple associated monitors may become unknown (blue) after a monitor rule change to one of its associated monitors. The expected behavior is that the node should remain 'green' if monitoring is successful with the new rule, but the node may become unknown (blue) until bigd is restarted.
The pool member status correctly reflects whether monitoring is successful (green) or the pool member is unknown (blue), but the changed monitor rule may not take effect until bigd is restarted.
A pool member is configured through an FQDN node, and has multiple associated monitors, and a monitor rule change is made to one of the associated monitors.
When making changes to a monitor rule associated with a pool member configured through FQDN, verify the node remains monitored (green or checking), or restart bigd. Alternatively, change monitor rules within the configuration file, and reload the configuration.
Pool members configured through FQDN nodes and with multiple associated monitors continue to be monitored after a monitor rule change to one of the associated monitors. This issue is resolved by the FQDNv2 feature re-implementation in this version of the software.