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 and pool) are being ignored.
Specifically, every command in the rule seems to be executed but them. Let's say I have hosts 192.168.1.10 and 192.168.1.15 in the pool, and 192.168.1.20 in the same LAN but outside the pool. This is the code I'm using:
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/refresh" } {
log local0. "forwarding packet to 192.168.1.20"
node 192.168.1.20 80
}
else {
log local0. "pool used is [LB::server pool]"
pool [LB::server pool] member 192.168.1.10 80
}
}
I can correctly see all logs I say to write, and commands like [LB::server pool] are working as expected. But! I only see the packet been forwarding to the pool members in a round robin cycle (the balancing method for the pool).
Am I missing something?
Try with a oneconnect profile on your VS to see if it changes anything?
IanBEmployee
In my lab, your irule worked as expected - that is to say:
- When I request "/refresh", the node selected is 192.168.1.20:80
- When I request "/" (or any other URI), the pool member selected is 192.168.1.10:80
Because your rule explicitly sets the node/member for every request, you should not be seeing normal load balancing (round robin in your case) at all.
I'm not able to tell from the information here why it's not working for you. It might help to add logging in an LB_SELECTED event, for example:
when LB_SELECTED { log local0. "[LB::server] was selected" }Then make some curl requests from the LTM itself, to eliminate anything else that might be getting in the way
ltm curl -v http://x.x.x.x/refreshAlso, make sure you're working with the active member of the HA pair, and that the pair is in config sync
Try with a oneconnect profile on your VS to see if it changes anything?
Michele_Cereda_The 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?
- IanBAh, 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.
- Michele_Cereda_
PS: the Big-IP version I'm using is 11.6.0 (build 5.0.429), for who asked.
- IanBThanks. I'm still digging into the issue with fastL4 with http and irule events. I've sent it up to PD for comment.