Forum Discussion

raytapay_75679's avatar
raytapay_75679
Icon for Nimbostratus rankNimbostratus
Sep 21, 2018

How F5 LTM Handles Long Server Responses

The article in the link below was really great but was missing some useful information that would have been helpful. Let's take a simple http VIP with no persistence or OneConnect. What would happen to the connections below, especially connection 3 (open and active) when the server stops responding and Action on Service Down is set to None? Let's also add some seconds to this. Let's say the keep alives are sent every 15 seconds so 46 seconds later the server is considered down. From the note below is says TCP mechanisms will take over. Does that mean that the LTM will re-start the 3 way hand shake and maybe because the Syns will not receive a responses back (syn acks) the Max Syn Retransmission (default value of 3) kicks in and 21 seconds later a reset is sent to the client and the client will hopefully re-initiate the connection which will lead to a new server being picked?

Connection 1 is brand new, still awaiting the response to the handshake SYN packet;
Connection 2 is open but idle;
Connection 3 is open and active.

None (default) LTM will continue to send data on established connections as long as client is sending and server is responding. Connection management / recovery / cleanup is via standard TCP mechanics for both clientside and serverside flows.

https://devcentral.f5.com/articles/ltm-action-on-service-down

https://devcentral.f5.com/articles/investigating-the-ltm-tcp-profile-max-syn-retransmissions-amp-idle-timeout

1 Reply

  • What would happen to the connections below, especially connection 3 (open and active) when the server stops responding and Action on Service Down is set to None?

    Connection 1 is brand new, still awaiting the response to the handshake SYN packet;  
    Connection 2 is open but idle;
    Connection 3 is open and active.
    

    Let's say the keep alives are sent every 15 seconds so 46 seconds later the server is considered down.

    I'm assuming you mean monitor probes, and not TCP Keepalives.

    Connection 1 - brand new, still awaiting the response to the handshake SYN packet:

    The LTM will retry SYNs until the server-side connection establishment fails.

    Since you specify an http profile, the client-side is established and has issued a HTTP_REQUEST before the server-side starts the 3WHS - so the client gets a reset to close the Connection 1.

    Connection 2 - open but idle

    The pool member markdown does not impact existing, established connections.

    The connection stays established until either the tcp idle timeout, or the client makes a request. This could be a TCP keepalive packet.

    Once the client sends a packet destined for the pool member and fails to get a response on the server-side, there will be retries as defined by Max TCP retries, and if there is no response, resets will be sent to the client and pool member to forcibly close the connection.

    Connection 3 - open and active

    The pool member stops responding to packets from the LTM on the server-side connection.

    Max TCP retries kicks in, and the LTM sends a reset to the pool member and the client to close out the connection.