Last Modified: Oct 01, 2018
See more info
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, 12.0.0
12.1.0, 12.0.0 HF1, 11.6.1 HF2
Opened: Oct 07, 2015
Related AskF5 Article: K75280116
TMM may core during processing of a CCA-T.
Traffic disrupted while tmm restarts.
For every session there is Gx context and Main session Context. There are always stitched to same processing unit to have synchronous look ups when a flow arrives for the session. These contexts are mirrored on a different blades for high availability (HA). The issue occurs when the following events happen. 1. Main session moveds to a new processing unit (Failover) trigger. 2. This session is marked for deletion by RAR from PCRF or RADIUS Stop. 3. Session delete is initiated from main session by sending a local message. 4. Gx context has not yet moved to this processing unit. 5. CCR-T was sent for this session after asynchronous lookup for the Gx context and we freed the local message. This is the bug. (See explanation below) 6. Gx context moved 7. PCRF sends CCA-T came back and tried to look up local message queued to acknowledge to main session. 8. Local message was deleted at step 5 and TMM cored.
This release prevents freeing of the Gx context when a CCR-T is sent out even if the Gx session is remote (present on another tmm), which prevents the TMM core.