Bug ID 857769: FastL4+HTTP or FastL4+Hash-Persistence virtual servers do not work correctly in DSR mode.

Last Modified: Apr 17, 2024

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,,,, 13.1.4,, 13.1.5,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 14.1.4,,,,,,, 14.1.5,,,,,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 15.1.3,, 15.1.4,, 15.1.5,, 15.1.6,, 15.1.7, 15.1.8,,, 15.1.9,, 15.1.10,,,, 16.1.0, 16.1.1, 16.1.2,,, 16.1.3,,,,,, 16.1.4,,,,

Opened: Dec 04, 2019

Severity: 3-Major


Given a long-lived TCP connection that can carry multiple client requests (for example, but not limited to, HTTP requests), the BIG-IP system fails to forward requests after the forty-eighth one. The client will try re-transmitting the answered request, but the BIG-IP system will persist in dropping it.


The BIG-IP system fails to forward traffic.


This issue occurs when all of the following conditions are met: 1) The virtual server uses the FastL4 profile. 2) The virtual server also uses the HTTP or Hash-Persistence profiles. 3) The virtual server operates in DSR (Direct Server Return) mode (also known as N-Path).


Do not use the HTTP or Hash-Persistence profiles with a FastL4 virtual server operating in DSR mode. Note: It is fine to use an iRule that calls hash persistence commands (for example, "persist carp [...]") as long as the Hash-Persistence profile is not associated to the virtual server. This technique will allow you to persist on a hash based on L4 information that you can extract at CLIENT_ACCEPTED time. For example, the following iRule correctly persists a specific client socket to a pool member in a FastL4 DSR configuration: when CLIENT_ACCEPTED { persist carp [IP::client_addr]:[TCP::client_port] }

Fix Information


Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips