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, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1
Fixed In:
13.0.0, 12.1.2, 11.6.1 HF1
Opened: Feb 10, 2016 Severity: 3-Major
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.
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.
-- 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.
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.
ADAPT correctly processes successive iRule events exactly once for each adaptation, and the 'records adapted' statistic reports the correct number.