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 server is alive and occasionally returns rst, how do I detect the rst returned by the source station?
小白 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.
小白I know, but instead of analyzing the cause of rst, I need to listen to the rst returned by the server through irules and then return the page I defined to the client
- Paulius
MVP
小白 So what you want to happen is if clientA comes in and is balanced to PoolMemberC and then a reset occurs from PoolMemberC side you want the F5 to send a page with actual content to clientA rather than resetting the TCP connection? I'm not sure if you will be able to do this but it's possible I suppose. I have never had the necessity to return a page upon tcp reset because typically the reset is caused by an invalid request of some sort or the server just going down and in an instance like that you want the client to be able to receive new content rather than them knowing their connection was reset and they see some arbitrary page that they most likely will either ignore or wouldn't be able to interpret. What are you trying to solve for by doing this?
williems739Nimbostratus
TCP RST (Reset) from a server is typically caused by an invalid or unexpected packet received from a client. It is most commonly seen when a client attempts to communicate on a port that the server has no application listening on, or when a client attempts to initiate a TCP connection with a server while one is already established.
- 小白
I know, but instead of analyzing the cause of rst, I need to listen to the rst returned by the server through irules and then return the page I defined to the client。
jaikumar_f5Cirrus - 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.
- 小白
I 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.