Forum Discussion

Kamiza_49017's avatar
Kamiza_49017
Icon for Nimbostratus rankNimbostratus
Sep 03, 2010

Persistance and TCP RST confirmation

Hi All,

 

 

Please could you confirm what happens to the persistance entry if the LTM recieves an TCP RST from the node.

 

Would it clear the pesistance entry for that host as it is unavailible straight away and send to the request to the next availible host in the pool? Alternatively would it still honour the persistance pool and continue to send to the end node until the entry times out or the server is removed by a health check?

 

 

 

 

 

Regards Brett
config
design

1 Reply

Sort By
  • Chris_Miller's avatar
    Chris_Miller
    Icon for Altostratus rankAltostratus
    Sep 04, 2010
    It's my understanding that persistence entries aren't touched unless a node/pool member fails a monitor. What you're talking about is "Action on Service Down"

    http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/179/LTM-Action-on-Service-Down.aspx 

    
Reject
LTM will reap any active connection by sending a RST to both client & server immediately upon receiving any traffic on the connection after the pool member transitions to a DOWN state, and removing the connection from the LTM connection table.

Use "Reject" when you want LTM to explicitly close both sides of the connection when the server goes DOWN.  "Reject" is the most commonly used option for the service down setting.  This option often results in the quickest recovery of a failed connection since it forces the client side of the connection to close, in many cases triggering an automatic re-connect & re-send of the request in process.  Replicates BIG-IP 4.x behaviour when the "svcdown_reset" db variable is set to "enabled".

Drop
LTM will silently drop any new client data sent on established connections.  The connection remains in the connection table until 1) an LTM idle timer related to the connection times out or 2) either side closes the connection.

Use "Drop" when sending a RST to the client is not desirable. This method does not immediately reflect the server's state change to the client, and depends on the client to close or otherwise manage the connection.

Reselect
LTM will choose another pool member if one is available and rebind the client connection to a new serverside flow.  (Existing OneConnect flows may be re-used if available, or a new server connection will be established if necessary.) 

Use "Reselect" when the client can continue with a new server seamlessly.  The request in play at the time of state transition may be lost, so the client will need to be able to recover gracefully to use this option successfully.

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.

Use "None" if you don't want LTM to intervene in managing either side of the connection.  Useful if your servers may not be accepting new connections, but should be allowed to continue servicing existing connections when marked DOWN. Also supports custom monitoring designed to support connection bleeding and other non-standard state management schemes.