Forum Discussion
Michele_Cereda_
Nimbostratus
NimbostratusLoad balancing not bypassed by 'node' nor 'pool' commands in iRule
Hi all,
I'm trying to force a packet forward to a specific pool member when the pool receives a HTTP_REQUEST with a specific URI, but it seems the iRule commands to bypass balancing (namely, node a...
Try with a oneconnect profile on your VS to see if it changes anything?
Michele_Cereda_Nimbostratus
NimbostratusThe problem seemed to be caused by the Type parameter of the VS, that was set on Performance (Layer 4) instead of Standard.
Now the code is working. Thanks for your advices.
The thing that seems strange to me about this particular topic is that the editor warned me that the VS needed a different profile in case I tried to set something like that. Do you have any ideas why it didn't this time?
IanBEmployee
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.- Michele_Cereda_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?
- IanBSorry 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.