Bug ID 573075: ADAPT recursive loop when handling successive iRule events

Last Modified: Oct 01, 2018

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, 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

Fixed In:
13.0.0, 12.1.2, 11.6.1 HF1

Opened: Feb 10, 2016
Severity: 3-Major

Symptoms

After the first iRule resumes from being parked, ADAPT attempts to process the second iRule event repeatedly. The connection is aborted with RST cause 'ADAPT unexpected state transition'. The adapt profile statistic 'records adapted' reaches a very high number as it counts every attempt.

Impact

The connection is aborted with RST cause 'ADAPT unexpected state transition'. The 'records adapted' statistic reaches a very high number. Eventually the TMM crashes and the BIG-IP system fails over.

Conditions

-- A requestadapt or responseadapt profile is configured. -- An iRule is triggered on the ADAPT_REQUEST_RESULT or ADAPT_RESPONSE_RESULT event, that parks. -- The modified headers (from an ICAP server) arrive at the ADAPT filter while the first event is parked. -- Any iRule on the ADAPT_REQUEST_HEADERS or ADAPT_RESPONSE_HEADERS event does not park.

Workaround

If possible, arrange the iRules to avoid the conditions above. In particular, if there is no better way, it is possible to avoid this if there is an iRule on the ADAPT_REQUEST_HEADERS or ADAPT_RESPONSE_HEADERS event that parks.

Fix Information

ADAPT correctly processes successive iRule events exactly once for each adaptation, and the 'records adapted' statistic reports the correct number.

Behavior Change