Last Modified: Jul 30, 2026
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 15.1.10.7, 15.1.10.8, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 16.1.6, 16.1.6.1, 17.0.0, 17.0.0.1, 17.0.0.2, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.1.3.1, 17.1.3.2, 17.1.3.4, 17.5.1.3, 17.5.1.4, 17.5.1.5, 17.5.1.6, 17.5.1.8, 21.0.0, 21.0.0.1, 21.0.0.2, 21.0.0.3, 21.1.0, 21.1.0.1
Opened: Jul 31, 2019 Severity: 3-Major
On a VIPRION chassis provisioned as a vCMP host, mcpd on the secondary blades may restart and log errors similar to the following in /var/log/ltm: err mcpd[43273]: 01070734:3: Configuration error: DB validation exception, unique constraint violation on table (trunk_virtual_mbr) object ID (<guest_name> <PDE_interface>). A duplicate value was received for a non-primary key unique index field. DB exception text (Cannot update_indexes/checkpoint DB object, class:trunk_virtual_mbr status:13)... failed validation with error 17237812 Post-mcpd starts on secondaries, guests that were involved in the above error might adopt each other's identity and answer at a different mgmt address than their own
All services on the affected secondary blades restart. vCMP guests running on those blades are disrupted until MCPD recovers After MCPD recovers, some guests have corrupted identity and are now essentially unusable
All of the following conditions must be met: - The VIPRION system is provisioned as a vCMP host with one or more deployed guests. - An abrupt loss of inter-blade connectivity occurs without a graceful secondary disconnect. - A secondary blade subsequently reconnects to the primary.
No workaround, the guests that are corrupted once (when a different identity was taken) have to be deleted+recreated
None