Bug ID 689361: Configsync can change the status of a monitored pool member

Last Modified: Mar 26, 2020

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
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, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 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.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, 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.4, 14.1.0.5, 14.1.0.6, 14.1.2

Fixed In:
14.1.2.1

Opened: Oct 18, 2017
Severity: 3-Major

Symptoms

It is possible for a configsync operation to incorrectly change a monitor's state. For example, it can change an 'unchecked' monitor to 'up', when that unchecked monitor references a node that does not respond to ICMP requests. This may occur when a node does not respond to ICMP requests for exactly one of two paired devices, but a configuration change made to one device causes the 'up' status to be propagated to the 'unchecked' device. Other state changes are possible.

Impact

The configsync causes the monitor on the standby system to transition to an incorrect state, out of sync with the active system.

Conditions

Pool members are monitored and a configsync is initiated from a paired device.

Workaround

There is a workaround for the case described in 'Symptoms': Ensure network configuration such that a monitored node responds to ICMP requests from both (or neither) of each paired-device. Alternatively, initiate configuration changes only from the device to which the node does not respond to ICMP requests.

Fix Information

A configsync no longer causes an unexpected monitor transition on the standby system.

Behavior Change