Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP All
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.1.0, 12.0.0 HF1, 11.6.1 HF1, 11.5.4 HF2
Opened: Aug 17, 2015 Severity: 3-Major
When a secondary blade's mcpd starts up, it may continually restart, failing to load, when the primary blade has a certain configuration. The easiest way to reproduce this is to insert a new blade into an existing running cluster. This will happen when a link local IPv4 self IP is in use and the DB variable config.allow.rfc3927 is set to disabled (which is the default). It is not possible to create such self IPs unless the DB variable is first enabled, the object is created, and then the DB variable is disabled. In certain scenarios a secondary blade mcpd may go into a restart loop when receiving the configuration from the primary blade if ipv4 link local SelfIP addresses are in use enabled by DBKey config.allow.rfc3927.
Secondary blade will not become part of the cluster and will not be able to process traffic. Continual log messages will show up on existing blades announcing that mcpd is continually restarting.
This happens only on MCP startup on secondary blades, when a link local IPv4 self IP is configured, and when the DB variable config.allow.rfc3927 is set to disabled (which is the default).
Enable the config.allow.rfc3927 DB variable on the primary to suspend this validation.
When a link local IPv4 self IP is in use and the DB variable config.allow.rfc3927 is set to disabled (which is the default), mcpd would previously fail to start on a newly inserted secondary blade. This no longer occurs.