Forum Discussion
小白
Cirrus
Cirrushow do I detect the rst returned by the server?
HI, For example 2, I want to use irules to detect the rst of the source's response。 1.When the server goes down, return the response page 500 status via Monitors and irules； 2.When the s...
小白 As jaikumar_f5 recommended you should be able to use LB_FAILED in conjunction with HTTP::redirect in this event and send the user to a URL stating the reset was caused by the pool member being down. Other than that I believe your only other option is to increase logging and log resets from pool members. The issue here is the F5 automatically forwards the reset received from the server to the client if configured this way. Any action take will not be based on the reset the pool member sends but the action that occurs the next time the client attempts to connect to the pool member that it has a persisted connection to. This seems like a whole lot of work just to know where you are receiving a reset from if you aren't experiencing an issue related to this.
jaikumar_f5
MVP
MVPCirrus - Can you comment how many pool members would be present & what monitor you have at present.
Few things that i could think of is,
- Try using the LB_FAILED event with the selected pool member from LB::status pool cmd & throw respond with custom page.
- Get the status code from http response & throw respond with custom page.
小白Cirrus
CirrusI have over a hundred pools, each with 1 or 2 different servers, each bound to a vs, and I want to use irules to process the rst returned from servers into one of my default pages. So I see this page on the client side and I know that the server returned rst.
- Paulius
小白 As jaikumar_f5 recommended you should be able to use LB_FAILED in conjunction with HTTP::redirect in this event and send the user to a URL stating the reset was caused by the pool member being down. Other than that I believe your only other option is to increase logging and log resets from pool members. The issue here is the F5 automatically forwards the reset received from the server to the client if configured this way. Any action take will not be based on the reset the pool member sends but the action that occurs the next time the client attempts to connect to the pool member that it has a persisted connection to. This seems like a whole lot of work just to know where you are receiving a reset from if you aren't experiencing an issue related to this.
- 小白
This is a feasible solution, thank you！