Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
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.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 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.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.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9
Opened: Jul 14, 2014 Severity: 3-Major Related Article:
K15825
After deleting external data-group, importing a new or existing external data-group does not propagate to TMM. Although the import/modify individually seem to work as expected with no errors displayed in the web interface, the ltm log shows 'update queued', but does not show 'update finished' for the imported/modified datagroup. tmctl ext_class_stat command shows that the deleted data-groups are still in the TMM and existing data-groups stay the same and do not reflect the modification that are made to them via GUI.
iRules associated with the data-groups do not behave as expected if data-group is deleted and afterwards when data-group modifications are made.
The issue occurs when working in an administrative partition other than Common.
There are two options for workarounds: 1. Use short names for the data-group files. It is the long names that are problematic. This is the recommended workaround. 2. Reboot. This causes the mcpd to re-load the data-groups and corrects the situation.
After deleting external data-group, importing a new or editing existing external data-group now works as expected.