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

Sergio_Magra's avatar
Sergio_Magra
Icon for Nimbostratus rankNimbostratus
Jun 19, 2013

"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 n...
application delivery
dev
devops
iRules
Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Jun 24, 2013
If 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.