LB_FAILED is triggered when LTM is ready to send the request to a pool member and one hasn’t been chosen (the system failed to select a pool or a pool member), is unreachable (when no route to the target exists), has reached a queue limit, or is non-responsive (fails to respond to a connection request).
If the target fails to respond to a connection request, the “Maximum Syn Retransmissions” option in the TCP profile will affect the amount of time before LB_FAILED is triggered.
When a client doesn’t receive a response to the SYN, there is a defined algorithm for the specified number of re-tries. First retransmission if no response is typically 3 seconds, and typical back-off timer algorithm is to double the wait time after each failed attempt. Most TCP stacks set Max Syn Retransmits to 5, producing the following progression and timing out after 93 seconds:
11:26:24.455153 > S ...
11:26:27.452465 > S ...
11:26:33.452465 > S ...
11:26:45.452465 > S ...
11:27:09.452481 > S ...
11:27:57.452466 > S ...
telnet: connect to address Connection timed out

In past versions, LTM’s default TCP profile sets “Maximum Syn Retransmissions” to 4, so with the default setting, LB_FAILED would be triggered if server didn’t respond in 45 seconds:
 1st SYN:  0
 2nd SYN: +3 seconds
 3rd SYN: +6 seconds
 4th SYN: +12 seconds
 5th SYN: +24 seconds
LB_FAILED: 45 seconds

Reducing “Maximum Syn Retransmissions” to 2 will result in the trigger of the LB_FAILED event in 9 seconds, which makes recovery logic in the LB_FAILED event much more useful as a backup to monitoring.
Note: The LB_FAILED event is not triggered for Performance L4 virtual servers. There is an enhancement request to add this in BZ341776. Contact F5 Support for additional information.


  if { {[active_members poolName] < 2} } {
    pool fallbackPool
when LB_FAILED {
  pool errorPool