Forum Discussion

averync's avatar
Icon for Nimbostratus rankNimbostratus
Dec 12, 2018

iRule Event LB_FAILED - Triggered for Active Server-Side Connections?

Our application creates a "connection pool" to a VIP with 3 LDAP servers. These connections are created at application initialization.


The VIP's pool uses "Load Bal Method=Least Connections (member)" and "Priority Group Activation=Less than 1". The pool members have Priority Group values of: ldap-01 : 100 ldap-02 : 90 ldap-03 : 80


When the application is started All of its 'connection pool' connections go to ldap-01, which is what we want. And of course we want them to stay there unless ldap-01 becomes unavailable.


The application does not handle errors well, but cannot be changed (easily). I am trying to minimize the chance of the app seeing an error when we stop ldap-01 for maintenance. I want the VIP to switch to ldap-02 for an 'in flight' transmission that suffers a time-out or RST.


My question is this, Is is possible to use an iRule, such as the one below, to trigger selection of ldap-02 if the already established connection has a error, such as timeout or RST, when ldap-01 is stopped?


Reading the description of LB_FAILED I think the answer is No. LB_FAILED will fire when the initial VIP pool member connection is attempted (SYN) but that is the only connection-related condition that triggers LB_FAILED(?) If the server-side connection suffers a transmission time-out or an RST that will not trigger LB_FAILED, correct?


We have a 2 second health check, but the app is super busy and there are essentially always active requests.


If the iRule below is not the right approach is there another iRule event that will allow an LB::reselect to chose ldap-02 and re-send the request?


=== candidate iRule === when CLIENT_ACCEPTED { set retries 0 } when LB_FAILED { if { $retries < [active_members [LB::server pool]] } { LB::reselect incr retries } }


1 Reply

  • Avery,


    The LB_FAILED event does not trigger mid-connection, only when selecting the server. There is the CLIENT_CLOSED event and the SERVER_CLOSED event which will activate when there was a connection close between the client and the F5 or the server and the F5 respectively, but nothing that would activate only on a TCP error. It seems like F5 has not yet added a way in to determine whether a TCP connection was closed normally through a four-way close or if it was from a RST/time-out. As you can see in this article, it has been an issue for some time.


    If you explain more about your situation, maybe a workaround can be configured.