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, 11.1.0, 11.2.0, 11.3.0, 11.4.0, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.6.0, 11.6.1, 11.6.2, 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, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 11.6.0 HF5, 11.5.6
Opened: Dec 16, 2014 Severity: 3-Major Related Article:
K17052
In certain circumstances, some L4 flows may not be successfully remirrored when a standby BIG-IP comes online. This involves a race condition when there are multiple routes and/or gateways defined; if the new standby device does not yet have the lasthop information when it gets the mirrored flow.
Not all flows will have been successfully remirrored to the standby device.
Using mirroring with layer 4 virtuals, with gateways and/or static routes defined.
Usually "bigstart restart tmm" will recover most or all of the L4 flows. This does not work perfectly all of the time, but is far less likely to encounter the error condition than a "bigstart restart" or "shutdown -r".
The standby device ignores the route to the client when accepting mirrored connections. If failover occurs without a route back to the client, the connection will still fail on failover.