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

[JRahm]

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
 }
}

[LirazM]

Or you can just choose reset or drop from the Virtual Server config "Immediate Action On Service Down".

[JRahm]

Good call! I didn't realize that feature has been around for the virtual server since being introduced in 12.0. Always more preferable to use built-in features over iRules where possible.

[VB]

Hi,

Configuration example:

So if you would have 2 Virtual Server on the same IP,

just with different Source Filters.

Let’s say

VS-1 10.10.10.10:443 Source 192.168.0.0/16

and

VS-2 10.10.10.10:443 Source 0.0.0.0.0/0

Both with SSL/TLS and HTTP profiles

Question

1)

So if VS-1 is down based on no Pool members or Disabled

by an F5 Admin. traffic from 192.168.0.0/16 would get a TCP RST from VS-1 and

never hit VS-2?

2)

will an irule using "virtual" work in this case? or is there an other irule funktion that would do this?

https://clouddocs.f5.com/api/irules/virtual.html?highlight=virtual

when FLOW_INIT {

 if { [active_members testpool] < 1 } {

   virtual VS-2

 }

}

[JRahm]

Yes, if a virtual server of higher precedence is down but one of lower precedence is available, by default the lower one will not respond. You can, however, change this behavior with the tm.continuematching database variable by setting it to true:

tmsh modify /sys db tm.continuematching value true

tmsh save /sys config

[NOC_ACN]

Hello @JRahm 

Thanks for your explaination.

My question is: As i know, the local traffic policies execute before iRule. In my case, we have VS with backend pool, an iRule to redirect when pool member = 0 and a local traffic policy. When pool down, my VS run iRule (and send RST as well) instead of perform local traffic policy. Is that an expected behavior?

Thanks

[JRahm]

it depends on what your local traffic policy is doing. If you have a sanitized version of both the iRule and the policy, post them and I'll take a look.

[NOC_ACN]

Hi @JRahm 

I just shared both irule and policy that we are using via private chat. Could you help to take a look please?

Thanks