SERVER_CONNECTED and reject - how affects clientside
Hi, From my test when I use reject in SERVER_CONNECTED event then following sequence of events is triggered (hope that logging indicates order of events): LB_FAILED CLIENT_CLOSED SERVER_CLOSED I have HTTP::respond in LB_FAILED but it's not executed. What is the reason? In LB_FAILED clientside connection should be still open so iRule should be able to send response - but looks like it is not the case. Is reject in SERVER_CONNECTED somehow removing/disabling clientside TCP connection? If it is so is there any way to send HTTP response instead of TCP connection reset sequence? Piotr
iRule LB_FAILED event when not doing any load balancing
i have the following iRule on a standard virtual server without a default pool, no local traffic policies and no other iRules: when HTTP_REQUEST { log local0. "HTTP_REQUEST" TCP::close return } when LB_FAILED { log local0. "LB_FAILED" } when i perform a single HTTP request is it logical that the LB_FAILED event is triggered? i mean nowhere any selection is made and the client side TCP session is closed. so why the LB_FAILED?
Why default pool "Reselect Tries" to 0? Any downside to higher values? Wouldn't that prevent client failures?
I'm trying to digest Sol10640 (https://support.f5.com/kb/en-us/solutions/public/10000/600/sol10640.html) and all its implications. The "Reselect Tries" seems to address a frequent customer complaint - that when a server goes down (but before a health monitor has marked it as down), the F5 will still send client connection attempts to it, and fail the client's connection if the attempt to connect to the real server fails. Yet the default for "Reselect Tries" is 0. Why is this? Does that imply that there's some significant downside to consider in setting it above 0? I've never seen general guidance, but I would think for e.g. HTTP proxies, setting it to " of pool members - 1" might be the best approach. No? thx!