Lightboard Lessons: standard virtual server behavior when no pool members are available

In this episode of Lightboard Lessons, Jason answers a question from a member of the community about BIG-IP's full proxy architecture and the relationship between the clientside TCP session and its serverside counterpart when there are no pool members available.

Packet Capture Details

In each of the following sections, you'll find the packet captures between the client and the BIG-IP, and where appropriate, between the BIG-IP and the server.

Standard HTTP Virtual Server, SSL, Pool Available

In this first capture, everything is working as expected.

Standard HTTP Virtual Server, SSL, Pool Unavailable

Now, the pool members are all down and the virtual server state is down. Note that even though there are no back-end resources available to manage the client connection, the client-side TCP and SSL handshakes complete before the BIG-IP acknowledges and resets the connection. This makes sense, as the server-side of the connection is not initiated until the application request arrives. With SSL, that means the handshake must occur before the request can be decrypted and read.

Standard HTTP Virtual Server, SSL w/ discard iRule, Pool Unavailable

Even though it is expected, it might not be desirable for the BIG-IP to respond to the client at all if the back-end resources are unavailable. I had a use case for this way back in my customer days. My global load balancer (that was not an F5 device) marked its pool members up if it received any response at all, even if that response was a "successful" TCP/SSL handshake that resulted in an immediate RST. By applying this iRule that checks for the available state of the pool members and discards packets when there are none, you can prevent responses altogether.

when FLOW_INIT {
 if { [active_members testpool] < 1 } {
   discard
 }
}

Standard HTTP Virtual Server, SSL w/ reject iRule, Pool Unavailable

You might however need to be a good netizen for your particular clients and alert immediately that your service is not available without tying up the resources of your TCP and SSL stacks. In this case you can alter the iRule to reject instead of discard.

when FLOW_INIT {
 if { [active_members testpool] < 1 } {
   reject
 }
}