irule to select pool based on url

Here's a quick iRule example:

when HTTP_REQUEST {
    switch -gob [string tolower [HTTP::uri]] {
        "/dashboard*" { pool pool_B }
        "/" { pool pool_A }
        default { pool pool_A }
    }
}

But then you can also do this task with an LTM policy and no iRules at all. Remember to enable OneConnect in the virtual server and in the associated HTTP profile to be able to do this context-based load balancing.

Something like this: when HTTP_REQUEST { switch [string tolower [HTTP::uri]] { "/" { pool pool_A } "/dashboard" { pool pool_B } default { } } }

You can then add others as required, if you want do do partial matches using regex

If I may add,

If you do wildcard matching - the switch -glob option (which is actually not regex), you should put the more specific URIs first. If you put "/*" first, then all requests will match this.

You don't have to specify a default action, but it's recommended.

Hi All, Thanks for the help, i will try this irules asap.

The members in both of the pools are the same, just that the ports are different. pool_A is for 443 and pool_B is for 8000.

Should i enable the port translation at the virtual sever, so that it will translate from 443 to 8000 if it hit pool_B?

Thanks.

Should i enable the port translation at the virtual sever, so that it will translate from 443 to 8000 if it hit pool_B?

You absolutely must enable port translation in the VIP if you want this to work. Is it also that one pool is doing SSL and the other is not?

is there any problem that i will face??

Not if both are doing SSL. I was thinking that maybe one was doing SSL (the 443 pool) and one was not (the 8000 pool), in which case you'd have to also enable or disable the server SSL profile in the VIP according to the pool selection.

If you're controlling ALL pool access form the iRule, then no you don't have to add the pool to the VIP.

May i know what is OneConnect for and why is a must to enable it?

When you load balance to a server in a pool, the BIG-IP establishes direct TCP connections with that pool member (as a proxy would). If you're doing "content switching", where you're sending traffic to different pools based on some request criteria, you may run into a situation where the BIG-IP has an established TCP connection with one pool member and won't immediately sever that connection and start a new one somewhere else. The OneConnect profile (applied in the virtual server and in the associated HTTP profile) allows you to safely switch between pool members.

Please see the following solution article for more details:

https://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html?sr=47331370