Forum Discussion
Nimbostratus"No Error" configuration
Hi everybody,
We don't really know if what we are trying to do is correct or it is done in a different way. I will explain what we need:
We need to configure a BIG-IP LTM's HTTP Virtual Server in which if a connection from a client receive an error or timeout from the pool member, the BIG-IP try with another member instead of returning the error to the client. The Big-IP will only return an error (or redirection) if neither of the pool members responds in a right way.
With "error" we mean HTTP error code 400 or higher.
This could be applied to load balancing stateless or stateful (sticky sessions) .
Please let us know if we are wrong. We will appreciate your help.
Thanks in advance
Best regards
Sergio
7 Replies
- Kevin_Stewart
Employee
Take a look at the examples on the HTTP::retry wiki page. They use the HTTP::status command in the HTTP_RESPONSE to determine the error code and then retry the request.
https://devcentral.f5.com/wiki/irules.http__retry.ashx 
Sergio_MagraKevin,
Thanks a lot for the answer. I think that it is what we are looking for. We will test it.
What do you think about how many resources it will consume?
Best regards
Sergio- Kevin_StewartI don't believe it'll be too resource intensive. You're essentially cycling through the list of available servers until 1) one of them gives a good response, or 2) you run out of servers. It's always recommended of course to have adequate monitors so that you minimize the potential for bad responses.
- Sergio_MagraKevin,
thanks a lot for the answer.
I have another similar scenario: is it possible (and advisable) to send the client request to all the pool members at the same time and just take the fastest response and discard the others? In this case, if the response of the server is an error, then apply the HTTP::retry iRule.
What do you think?
Best regards - Kevin_StewartIf that worked at all I wouldn't recommend it. That would, hypothetically, require a significant overhead in processing and connection management.
The solution really depends on what you're trying to prevent:
* Massive server issues that manifest as 50x or other errors (something that would warrant taking the server out of rotation) - would be best served by a strong monitor.
* Transient errors like 500s that may happen because of momentary glitches in server processing - may be best suited to a variant of the previously mentioned iRule, where status codes are caught and new servers are tried (HTTP::retry) until either one of them answers with a good response or you run out of servers.
* Transient errors like 404s that may happen because of a specific user request (and not a server issue) - may be best suited to an iRule that simply catches the 404 and returns some generic content in its place. - Sergio_MagraOk, Kevin. Very clear answer.
Thanks a lot for your help.
Best regards - Sergio_Magra
Hi, regarding the HTTP::retry command, I have a question for you:
Instead (or in addition to) retrying after a bad server response, it is a common configuration to wait for a timeout from the server to decide retrying to the next available server?
Thanks in advance
Best regards
Sergio Magra
