cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
JRahm
Community Manager
Community Manager

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.

0151T000003dH6nQAE.png

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.

0151T000003dH6xQAE.png

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

0151T000003dH9DQAU.png

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

0151T000003dH9IQAU.png

Comments
LirazM
Nimbostratus
Nimbostratus

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

JRahm
Community Manager
Community Manager

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

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
Community Manager
Community Manager

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

 

 

 

Version history
Last update:
‎13-Jun-2019 04:33
Updated by:
Contributors