Bug ID 636842: A FastL4 virtual server may drop a FIN packet when mirroring is enabled

Last Modified: Oct 30, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP All(all modules)

Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 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, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 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, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 15.0.0, 15.0.1

Opened: Jan 04, 2017
Severity: 3-Major
Related AskF5 Article:
K51472519

Symptoms

A FastL4 virtual server may drop a FIN packet when mirroring is enabled.

Impact

The BIG-IP system forwards the RST packet but not the FIN packet. As the RST sent by one of the TCP endpoints would have its sequence number increased by 1 to account for the FIN packet, the other TCP endpoint may not accept the RST as the FIN packet was never seen. This issue is exacerbated if the FIN packet also carries application data (for example, if it is actually a FIN,PSH,ACK packet). In this case, the other TCP endpoint never sees the application data contained within the packet, and the sequence number in the RST will be off by more than just 1. Ultimately this can cause application failures and also the two connection flows to stall for some time.

Conditions

- The virtual server uses the FastL4 profile. - The virtual server performs mirroring. - The tm.fastl4_ack_mirror db key is enabled (default). - The client or the server sends a FIN packet, immediately followed by a RST packet.

Workaround

To workaround this issue you can either: 1) Disable mirroring for the virtual server (but this comes with a loss of functionality, which may not be acceptable). or 2) Disable the tm.fastl4_ack_mirror db key (but this would affect all FastL4 virtual servers performing mirroring on the box).

Fix Information

None

Behavior Change