Last Modified: Jul 13, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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, 12.1.5.1, 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, 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
Fixed In:
15.0.0, 14.1.2.1, 13.1.3.2, 12.1.5.2
Opened: Oct 18, 2017 Severity: 3-Major
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.
The configsync causes the monitor on the standby system to transition to an incorrect state, out of sync with the active system.
Pool members are monitored and a configsync is initiated from a paired device.
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.
A configsync no longer causes an unexpected monitor transition on the standby system.