Immediate reset when all nodes for a VS are unavailable

The reason you're seeing a completed TCP handshake is due to the new Full-Proxy architecture of BIG-IP version 9.x. This architecture uses seperate connections to the client and server to transfer information, so the TCP handshake you're seeing on the client side is with the BIG-IP, not with the end server.

As far as an immediate disconnect, I think the closest you're going to see in a rule is if you use the LB_FAILED command, and immediately send the desired response to the client, and terminate the rule.

THis would look something like :

when LB_FAILED {
  TCP::respond $myResponseData
  TCP::close
  return
}

This is, of course, just a general example, and not tested.

-Colin

Which profile are you using? For TCP and FastHTTP, there is no way to do this, as these profiles offload the handshake and proxy the traffic; by the time the LB pick is made, the handshake has already completed. If you're using fastL4 it might be do-able, since I believe (without looking at the code) that an lb-failed event with fastL4 triggers a RST to the client.

You are correct, the full-proxy completes the handshake prior to making any LB decisions. I resorted to using the FastL4 profile which makes the BigIP act like a half-proxy; however, it does not send a reset back to the requestor. It discards the packets and sends nothing back to the client.

 

According to the application owners, receiving nothing is more acceptable than a complete handshake and a reset.

 

Thank you for everyone's support!!

Looking at the code, I can see where we drop the SYN silently if we weren't able to connect to a viable server in fastL4. I can see an argument for having this be configurable on the profile so that we send a RST instead (or, with more iRule versatility, allowing RSTs to be sent via an abort command from the LB_FAILED handler in fastL4.)

 

 

If you need this addressed, please contact support and have them send us a case so we can open an RFE CR.