Reselct based on http response code 503
Below is the irule I am using when CLIENT_ACCEPTED { set retries 0 set default_pool pool-name } when HTTP_REQUEST { if { [HTTP::method] eq "GET" && $retries == 0 }{ set request_headers [HTTP::request] log local0. "Saving HTTP request headers: $request_headers" } } when LB_SELECTED { if { $retries > 0 } { LB::reselect pool $default_pool } } when HTTP_RESPONSE { if { [HTTP::status] starts_with "503" } { log local0. "503 error caught: retry $retries out of [active_members $default_pool]" if { $retries < [active_members $default_pool] } { HTTP::retry $request_headers return } } set retries 0 } Below are the things I noticed. Client side is hung with no responses. F5 is not giving the request to other working members which doesn’t have a 503. So we can alter the irule to send to other members in the next retry itself instead of sending to existing node. We are having a VIP with FQDN nodes with IP based persistence
FQDN Pool member failing becuase previously added by IP
I ran into an interesting problem on 12.1.2 and was wondering if this is expected behavior, and if so, why? I had a pool that had a member(node) added by IP with a basic TCP monitor, which worked. I then had a requirement to point to this node by FQDN. After creating the new FQDN pool with a basic TCP monitor, I noticed it would not go green, with /var/log/ltm showing member not found error. This made no sense to me, since I could resolve the FQDN from the CLI and that fact that I was looking at the member as green in the original pool. To resolve the issue, I deleted the node previously created by IP. Once I did that and forced a new resolution, it worked! Any thoughts? If nothing else, hopefully this helps someone else out.