Forum Discussion

Anna_Novikova_1's avatar
Anna_Novikova_1
Icon for Nimbostratus rankNimbostratus
Apr 23, 2014
Solved

Is it possible to store (HTTP) requests from cliens for some period

I have a passive monitor when the system marks the pool member as down when receives a bad response. Now I'm researching the way when the system receives a bad response will immediately resend reques...
  • nitass_89166's avatar
    Apr 23, 2014

    i understand passive monitor and HTTP::retry do similar thing i.e. take an action based on response content.

    sol7440: Overview of passive health monitoring

    http://support.f5.com/kb/en-us/solutions/public/7000/400/sol7440.html

    inband monitor is one type of health check. it has no error handling but LB::reselect or reselect tries can be used to provide appropriate action as Kevin suggested.

    Inband

    http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_appendixa_monitor_types.html
    Improving the default behavior using the Inband monitor feature (10.x or later)
    
    Beginning in BIG-IP 10.x, the Inband monitor type was introduced. The Inband monitor determines the availability of a pool member based on a specified number of failed connection attempts or data request attempts within a specified time interval. This monitor works in parallel with regular monitors, and can be used instead of the LB::down iRule command.
    
    Note: For more information about the Inband monitor, refer to the Configuration Guide for BIG-IP Local Traffic Management.
    
    The Inband monitor provides no error handling for in-progress connections. Therefore, it does not replace the LB::reselect functionality. However, beginning in BIG-IP version 10.x it is possible to cause a reselection by using the Reselect Tries advanced pool feature. This feature is equivalent to the LB::reselect iRule command. Once a connection attempt to a pool member is considered failed (equivalent to the LB_FAILED iRule event), the BIG-IP system selects a new pool member. Should that pool member also fail, the system repeats the reselection until it reaches the limit configured for this option. Only at this point is the client connection reset.
    
    Note:  Do not confuse this feature with the Reselect option under the Action on Service Down advanced pool feature, which manages established client connections by moving them to an alternative pool member when monitors mark the original pool member down.
    
    As a result, in BIG-IP 10.x and later, you can avoid many failure situations without the need for an iRule since the combination of Inband monitors and the Reselect Tries feature can be used instead of the LB::down iRule command and the LB::reselect iRule command. iRules continue to offer greater flexibility and you can still use them in combination with these features where a particular behavior is required.
    

    sol10640: Pool member reselection options

    http://support.f5.com/kb/en-us/solutions/public/10000/600/sol10640.html