iRule URI rewrites don't always use the correct pool

Forums Technical Forums
,
1

Hello F5 community!

I have created an iRule for specific URI rewrites, but it seems that the requests are not getting directed always to the proper pool.

Example:
We want www.example.com/api/views to use the 9231 pool.
However some requests are ending up to different pools as well, even though the rewrite is correct.

I have attached the traffic logs and the irule configuration as well.

I’d appreciate your feedback!
Thank you in advance.

Nikos

2

Adding the logs and config here as well.

Logs:

Fri Nov 1 05:23:59 PDT 2024    info    dbs02bigip1    tmm[19251]         Rule /Common/example.com <HTTP_REQUEST>: /Common/example.com-https_vs - client ip= 162.158.38.180:10252, Source_IP: 18.200.185.153, 162.158.38.180, HTTP URI Before= example.com/api/views

Fri Nov 1 05:23:59 PDT 2024    info    dbs02bigip1    tmm[19251]         Rule /Common/example.com <HTTP_REQUEST>: /Common/example.com-https_vs - client ip= 162.158.38.180:10252, Source_IP: 18.200.185.153, 162.158.38.180, HTTP URI After= example.com/views, Pool: /Common/example.com_http_9241_pool 172.22.1.18 9241

Fri Nov 1 05:24:05 PDT 2024    info    dbs02bigip1    tmm[19251]         Rule /Common/example.com <HTTP_REQUEST>: /Common/example.com-https_vs - client ip= 162.158.38.35:60024, Source_IP: 18.200.185.153, 162.158.38.35, HTTP URI Before= example.com/api/views

Fri Nov 1 05:24:05 PDT 2024    info    dbs02bigip1    tmm[19251]         Rule /Common/example.com <HTTP_REQUEST>: /Common/example.com-https_vs - client ip= 162.158.38.35:60024, Source_IP: 18.200.185.153, 162.158.38.35, HTTP URI After= example.com/views, Pool: /Common/example.com_http_9231_pool 172.22.1.18 9231

iRule config:

when HTTP_REQUEST {
    log local0. “[virtual] - client ip= [IP::client_addr]:[TCP::client_port], Source_IP: [HTTP::header X-Forwarded-For], HTTP URI Before= [HTTP::host][HTTP::uri]”
    if { [HTTP::uri] starts_with “/api/settings” } {
        set uri [string map -nocase {“/api/settings” “/settings”} [HTTP::uri]]
        HTTP::uri $uri
        pool example.com_http_9231_pool
    }
    elseif { [HTTP::uri] starts_with “/api/views” } {
        set uri [string map -nocase {“/api/views” “/views”} [HTTP::uri]]
        HTTP::uri $uri
        pool example.com_http_9231_pool
    }
    elseif { [HTTP::uri] starts_with “/api/stripe/payment” } {
        set uri [string map -nocase {“/api/stripe/payment” “/payment”} [HTTP::uri]]
        HTTP::uri $uri
        pool example.com_http_9311_pool
    }
    elseif { [HTTP::uri] starts_with “/api” } {
        set uri [string map [list “/api” “” ] [HTTP::uri]]
        HTTP::uri $uri
        pool example.com_http_9241_pool
    }
    elseif { [HTTP::uri] starts_with “/ns” } {
        set uri [string map -nocase {“/ns” “”} [HTTP::uri]]
        HTTP::uri $uri
        log local0. “[virtual] - client ip= [IP::client_addr]:[TCP::client_port], Source_IP: [HTTP::header X-Forwarded-For], HTTP URI After= [HTTP::host][HTTP::uri]”
        if { [string tolower [HTTP::header Upgrade]] contains “websocket” } {
            HTTP::disable
        }
        pool example.com_http_9291_pool
    }
    elseif { [HTTP::uri] starts_with “/auth” } {
        HTTP::header insert X-Forwarded-Host [HTTP::host]
        pool example.com_http_8080_pool
    }
    else {
        pool example.com_http_8001_pool
    }
    log local0. “[virtual] - client ip= [IP::client_addr]:[TCP::client_port], Source_IP: [HTTP::header X-Forwarded-For], HTTP URI After= [HTTP::host][HTTP::uri], Pool: [LB::server]”
}

3

@dra1nbama9e Can you please provide the configuration of your virtual server that this is associated to? My guess currently is that that host was sent to the incorrect pool previously and when the new request came in again for the new path it went to the old pool. You can try configuring a /32 OneConnect profile and configuring it on the virtual server in question to see if that corrects the issue.

4

can you verify that this part is ok?
it seems different from examples in string map

…

elseif { [HTTP::uri] starts_with “/api” } {
        set uri [string map [list “/api” “” ] [HTTP::uri]]
        HTTP::uri $uri
        pool example.com_http_9241_pool
    }

…

5

Hello @Paulius
Thank you for the prompt reply. Indeed I configured a /32 oneconnect profile and now is seems that all the requests are redirected only to the correct pool.
Not sure I understand why though :smiley: !

6

Hello @zamroni777
Thank you for the prompt reply.
I’ll make sure it’s correct and I’ll get back to you.

7

@dra1nbama9e The reason this happens is because the iRule to pool match is only performed on the initial HTTP request from the client. So when the client comes in they match a different part of the iRule and get sent to that pool and then from that point forward every subsequent request is then sent to that same pool. With a OneConnect profile every HTTP request is looked at and a iRule validation of that request is made. The primary use of the OneConnect profile is to reuse connections between the F5 and the pool member but the side-effect is that it looks at every HTTP request and analyzes them separately. The following might help you with some additional understanding.