Load balancing not bypassed by 'node' nor 'pool' commands in iRule

Ah, I see what's happening. For fastL4, LB_SELECTED happens before HTTP_REQUEST, so the pool command in your irule would have no effect. I'm trying to find some documentation to back that assertion up.. I'll see what I can dig up.

It seems to be like you say, since the log in the LB_SELECTED block is recorded **before** the ones in the HTTP_REQUEST block. I was wondering.. I found out that multiple `node` or `pool` commands just overwrite the final destination selection, so that only the last one is considered valid. If the LB_SELECTED happens before the HTTP_REQUEST, and it should since the log commands in the latter were executed after the selection, shouldn't the HTTP_REQUEST block reselect the destination node or pool invalidating the selection made in the LB_SELECTED block? Because it seems they are just ignored. Is the selection in the LB_SELECTED block final?

Sorry about the delay. I can confirm that this is expected behaviour when using FastL4 + HTTP. The HTTP profile was enhanced to allow it be added to a fastL4 to support the PEM product, but it is currently quite limited in what it can do (see SOL16446), as the intended use was only with the PEM. module. As a result, in this scenario, HTTP_REQUEST fires after LB_SELECTED, at which point it is too late to change the selected pool member. As you've noted, modifying the virtual server to be of type 'standard' resolves the issue.