Bug ID 797253: GTM objects may have different availability states on different blades

Last Modified: Mar 21, 2023

Bug Tracker

Affected Product:  See more info
BIG-IP DNS, GTM(all modules)

Known Affected Versions:
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, 15.1.8,

Opened: Jun 24, 2019
Severity: 3-Major


After a reboot or restart of services, gtmd may fail to update tmms on secondary blades of the state of a pool or wide IP. This can occur when tmm has failed to load the full GTM configuration at the time that the state change occurs. With tmm debug logging enabled you may see logs like: -- alert gtmd[12211]: 011a3004:1: SNMP_TRAP: Wide IP /Common/wideip-9998.com state change blue --> red (No enabled pools available) -- debug tmm[20057]: 011ae0f9:7: Encountered problem while processing mcp message at ../gtmdb/db_gtm_wideip_state.c:88 : Wideip not found during attempt to set state. Will reprocess message later. If the configuration still fails to load the object after 60 seconds, the message may be deleted and the state change is lost.


Wide IP queries may give different results depending on which blade the query hits.


- Multi-bladed system. - Reboot or restart of services. - tmm is slow to load configuration due to size (e.g., because of many thousands of objects).


Increase the tmm.mcp.replay.timeout: tmsh modify sys db tmm.mcp.replay.timeout value 240

Fix Information


Behavior Change