Last Modified: May 19, 2023
Known Affected Versions:
14.1.0, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 14.1.2, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 14.1.3, 220.127.116.11, 14.1.4, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 14.1.5, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 15.0.0, 15.0.1, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124
Opened: Apr 16, 2019 Severity: 3-Major
If a virtual server starts with a FastL4 profile with an idle_timeout of zero, and this profile is then replaced with one that has a non-zero idle_timeout, it can cause traffic to fail with a 'No flow found for ACK' error in the RST packet (if DB variable tm.rstcause.pkt is enabled) or logged (if DB variable tm.rstcause.log is enabled).
Traffic no longer passes through the virtual server properly.
-- There is a virtual server configured with a FastL4 profile with an idle-timeout setting of zero ('immediate'). -- The FastL4 profile is replaced with one that has a non-zero idle-timeout setting.
To avoid this issue, if you need to change the FastL4 profile in this manner, delete and recreate the entire virtual server rather than replace the profile. Impact of workaround: This results in a traffic disruption for that virtual server. If the issue has already occurred, the only way to recover is to restart TMM Impact of workaround: This also results in a traffic disruption, this time a general one.
Replacing a virtual server's FastL4 profile no longer causes traffic to fail in this scenario.