Connection Reset a while after node offline
Hi, Setup: HTTPS virtual server with a pool, SNAT automap and OneConnect. Action on service down is reject, monitor is http result code checking. iRules (in order of precedence) Maintenance page Inserting X-Forwarded-For: and more header work, possible pool selection and HTTP::respond based on URI.. The issue: Suppose there is node01 and node02. I get cookie persisted to node01. When I shut down node01 and refresh the page, I get a connection reset. This is the same for about 10 seconds and then I get persisted to the new node. If I do not include the return in the maintenace irule, I get the maintenance page. Any ideas why it takes 10 seconds before I get persisted to the new node? When I assign an inband monitor, the first request will fail but subsequent ones will work. How can I make ANY request work? When picking reselect and max_reselect to 3, everything works. But is this ideal?
Unable to consistently send resets with irule using documented methods
I need to create an irule that looks for the string "error" in the HTTP response, and if it is found sends a reset back to the client rather than the response with "error" that was analyzed by the F5. Based on the irule documentation I thought it would work using the -reset flag during an http::respond, but despite our f5 version supposedly supporting it an error appears in the LTM log when the -reset flag is set and it does not function properly. When I used reject, it does sometimes send a reset as the response, but not always as expected. I can confirm that the if statements are being utilized do to the log entries, but non of the documented irule solutions to send a reset seem to work as described in the documentation. Also, now with this redesign of devcentral, it is significantly more difficult to use this site and find any relevant info or documentation about the topic. Does anyone know of a way to consistently get this reset to be sent when "error" is found in the response? Unrelated, but I also found that there is a limit of the amount you are able to post in devcentral questions, however it does not limit you from entering as much as you want in the question text field and the error you get is just a generic "please contact sysadmin error" so you have to figure that out yourself; seems like a lot about this site is broken, particularly after the new redesign.