Bug ID 990173: Dynconfd repeatedly sends the same mcp message to mcpd

Last Modified: Sep 29, 2022

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.4,, 12.1.5,,,, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,,,, 13.1.4,, 13.1.5,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 14.1.4,,,,,,, 14.1.5,,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 15.1.3,, 15.1.4,, 15.1.5,, 15.1.6,, 15.1.7, 16.0.0,, 16.0.1,,, 16.1.0, 16.1.1, 16.1.2,,, 16.1.3,,

Opened: Feb 03, 2021
Severity: 4-Minor


If dynconfd sends a single message to mcpd containing two or more operations, and one of the operations fails mcpd validation, dynconfd repeatedly sends same message to mcpd. An example of two operations in one mcp message would be an ephemeral node creation and an ephemeral pool member creation in a single mcp message.


By repeatedly resending the same messages, which fail repeatedly, dynconfd causes increased mcpd CPU utilization. This might cause the population of ephemeral nodes and pool members to fail and become out of sync with what the DNS server is resolving.


This can occur when: -- Using FQDN nodes and FQDN pool members. -- There is an additional issue where the message from dynconfd fails validation within mcpd (e.g., a misconfiguration in which the monitor assigned to the pool is configured with a wildcard destination and the pool member is added to the pool with a port of '0' or 'any'.


Examine the LTM logs for mcpd error messages indicating failed attempts to create ephemeral nodes or ephemeral pool members, and resolve the cause of the failed node or pool-member creation.

Fix Information


Behavior Change