22-Oct-2023 22:48 - edited 23-Oct-2023 01:19
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?
Solved! Go to Solution.
24-Oct-2023 11:13
@小白 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.
23-Oct-2023 01:43 - edited 23-Oct-2023 01:44
Sorry, I don't quite get it。I want to get the rst returned by the server through irules
23-Oct-2023 07:26
@小白 When the server issues a reset on the HTTP connection that already is sent to the client. For a reset based on a health monitor failure this can be configured in the "Action On Service Down" in the pool configuration and is the option "Reject" to issue the reset.
24-Oct-2023 00:07
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
24-Oct-2023 06:43
@小白 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?
24-Oct-2023 08:04
My f5 device is the intermediary agent, and I want to distinguish this way whether the rst is an internal cause or a server cause.
24-Oct-2023 00:03
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.
24-Oct-2023 00:06
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。
24-Oct-2023 08:09
@Cirrus - Can you comment how many pool members would be present & what monitor you have at present.
Few things that i could think of is,
24-Oct-2023 08:17
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.
24-Oct-2023 11:13
@小白 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.
25-Oct-2023 23:25
This is a feasible solution, thank you!