Bug ID 572142: Config sync peer may fail to monitor newly added pool member after it is added via sync

Last Modified: Apr 24, 2024

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

Known Affected Versions:
11.2.1, 11.4.1, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.1, 11.6.2, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 13.1.3,,,,,,, 13.1.4,, 13.1.5,,, 14.1.5,,,,,,, 15.1.6,, 15.1.7, 15.1.8,,, 15.1.9,, 15.1.10,,,,,, 16.1.3,,,,,, 16.1.4,,,

Opened: Feb 05, 2016

Severity: 3-Major


If a pool member in a sync group is removed and another member added and then synced to the peer, the monitor state on the peer may be erroneous.


Monitoring does not happen. If the pool member should be marked down by the monitor, it may indicate as being up. You may need to do a system restart to get monitoring to resume properly.


2 or more devices in a device group A pool member is deleted, and another is added, then a full config sync is performed


Suggested workaround: Here’s a way that should avoid any possible downtime: 1. Do the node replacement on box A. Do not sync. 2. Do the node replacement on box B. Do not sync. 3. This will cause a sync conflict, and its resolution will require a full load. This is intentional. Force a sync. The result of that final sync will be that mcpd sends no changes to the relevant nodes on the receiving device.

Fix Information


Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips