Bug ID 633402: In rare circumstances, the use of persistence can cause a TMM memory leak.

Last Modified: Jan 16, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 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.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:
13.1.0

Opened: Dec 14, 2016
Severity: 3-Major
Related AskF5 Article:
K25504871

Symptoms

TMM leaks memory in the 'tcl' subsystem. This can be observed, for example, by monitoring the output of the 'tmsh show sys memory' command over time.

Impact

As TMM memory utilization grows, TMM will first attempt to free up memory by removing idle flows. As a result, you may experience flows are expired before their configured idle timeout. Ultimately, TMM can crash if it is unable to allocate memory. Traffic will be disrupted while TMM restarts.

Conditions

Currently, the only known circumstance is when all of the following conditions apply: - You have a standard UDP virtual server. - You have an iRule calling the 'persist' command under 'CLIENT_DATA'. - Load balancing of the UDP flow fails as the assigned pool has no available members.

Workaround

Within the context of the known circumstance, you can work around this issue by moving the 'persist' command to the 'CLIENT_ACCEPTED' event.

Fix Information

None

Behavior Change