For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

JimRiley_106607's avatar
JimRiley_106607
Icon for Nimbostratus rankNimbostratus
Jan 18, 2012

persistant connection

An active in-use node has two health monitors. One health monitor fails and the F5 properly sets the node to RED diamond / inactive state. However, the F5 still sends data to the node. The data in this case is from the same originating device and same IP address, within a few minutes of the failed health monitor.

 

I need to immediately stop data traffic to the node when either health monitor fails.

 

How can I get the F5 to break any existing remnant persistance, and send data to other alternate nodes (which would still be green/active)?

 

thanks
application delivery
dev
devops
iRules

3 Replies

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jan 18, 2012
    Hi Jim,

     

     

    You can set the pool option for 'action on service down' to reset. The default is to leave existing connections as they are.

     

     

    Aaron
  • JimRiley_106607's avatar
    JimRiley_106607
    Icon for Nimbostratus rankNimbostratus
    Jan 19, 2012
    The Action on UNavailble was set to RESELECT, which seems like it would stop existing connections to node-1 and move over to node-2, but it wasn't.

     

     

    You mention a RESET option, I guess that would mean the REJECT option, since the help states that will do a 'RST' (reset).

     

     

    I will tryout the REJECT option; would the DROP also work - as long as the F5 will begin using the node when the health checks report it is again ACTIVE (available).

     

     

    Jim Riley

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jan 19, 2012
    Reselect only works for these cases:

     

     

     

    http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-1-0/ltm_pools.html

     

     

    You should configure the system to select a different node in certain cases only, such as:

     

    •When the relevant virtual server is a Performance (Layer 4) virtual server with address translation disabled.

     

    •When the relevant virtual servers Protocol setting is set to UDP.

     

    •When the pool is a gateway pool (that is, a pool or routers)

     

     

     

    And yes, I meant reject which sends a reset for TCP connections. Drop would potentially work as it removes the LTM connection table entry and causes LTM to send a reset to the client and pool member on the next packet from either side. Reject just works quicker to get to the same point. No matter which option you select, LTM will start selecting the pool member again for new connections once it's marked up by the monitor(s).

     

     

    Aaron