Forum Discussion
Is it possible to store (HTTP) requests from cliens for some period
- 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.htmlinband 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.htmlImproving 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
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.htmlinband 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.htmlImproving 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.htmlRecent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com