Request always going to default

Have you enabled oneconnect? - you need to

OneConnect is definitely important. But also make sure you're accurately capturing the path. As a test, add some logging and see where traffic is actually going.

when HTTP_REQUEST {
    log local0. "path = [HTTP::path]"
    switch -glob [string tolower [HTTP::path]] {
        "/path1*" {
            log local0. "going to pool 1"
            pool POOL_serverpool2
        }
        "/path2*" {
            log local0. "going to pool 2"
            pool POOL_serverpool2
        }
        "/path3*" {
            log local0. "going to pool 3"
            pool POOL_serverpool2
        }
    }
}
when SERVER_CONNECTED {
    log local0. "LB server = [LB::server addr]"
    switch [LB::server addr] {
        "168.217.1.1" {
            log local0. "168.217.1.1"
            SSL::profile serverssl_server3
        }
        "168.217.1.2" {
            log local0. "168.217.1.2"
            SSL::profile serverssl_server4
        }
        "168.217.1.8" {
            log local0. "168.217.1.8"
            SSL::profile serverssl_server5
        }
    }
}

If I enable oneconnect, won't it continually disconnect and reconnect a session to the back end servers since I am doing https / server-side ssl to the back end?

If I enable oneconnect, won't it continually disconnect and reconnect a session to the back end servers since I am doing https / server-side ssl to the back end?

but only one server ssl handshake per connection is done, isn't it?

e.g.

 config

root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
    destination 172.28.24.10:443
    ip-protocol tcp
    mask 255.255.255.255
    pool foo
    profiles {
        clientssl {
            context clientside
        }
        http { }
        oneconnect { }
        serverssl {
            context serverside
        }
        tcp { }
    }
    rules {
        myrule
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 2
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool foo
ltm pool foo {
    members {
        200.200.200.101:443 {
            address 200.200.200.101
        }
    }
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule myrule
ltm rule myrule {
    when CLIENT_ACCEPTED {
  log local0. "[IP::client_addr]:[TCP::client_port]"
}
when CLIENTSSL_HANDSHAKE {
  log local0. "[IP::client_addr]:[TCP::client_port]"
}
when SERVER_CONNECTED {
  log local0. "[IP::client_addr]:[TCP::client_port]"
}
when SERVERSSL_HANDSHAKE {
  log local0. "[IP::client_addr]:[TCP::client_port]"
}
}

 client

[root@centos1 ~] ab -n 10 https://172.28.24.10/

 /var/log/ltm

[root@ve11a:Active:In Sync] config  tail -f /var/log/ltm
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50485
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50485
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule SERVER_CONNECTED: 172.28.24.1:50485
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule SERVERSSL_HANDSHAKE: 172.28.24.1:50485
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50486
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50486
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule SERVER_CONNECTED: 172.28.24.1:50486
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule SERVERSSL_HANDSHAKE: 172.28.24.1:50486
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50487
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50487
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50488
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50488
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50489
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50489
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50490
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50490
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50491
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50491
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50492
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50492
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50493
Feb  3 15:18:43 ve11a info tmm[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50493
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENT_ACCEPTED: 172.28.24.1:50494
Feb  3 15:18:43 ve11a info tmm1[13662]: Rule /Common/myrule CLIENTSSL_HANDSHAKE: 172.28.24.1:50494

Unless you have a very particular requirement for your serverside ssl, you should just use the default profile regardless of the server chosen - no need to switch it around. Even if you doo need multiple profiles there will just be one SSL handshake per connection as Nitass says.

As far as your pool selection goes based on path - you must have oneconnect enabled for it to work.

Thanks for the help guys.

I have added a oneconnect profile and yes you are correct one SSL handshake per connection.

I still have the same issue though with even oneconnect enabled.. I am starting to really believe its to do with the cookie persistence as the cookie does not match across pools and I do not have any expiration set.

The cookies not matching across pools is due to the two pools having different nodes.

Have you got logging enabled as Kevin suggested?

Yes I have. Path shows correct. But is not matched in irule even though query is exactly for that same path, so no logs are seen for the path. Logs on the ssl certificate does log correctly.

If I set persistence to source address the irule works. But this to me is not ideal and I require it to be cookie based persistence. Is there a way to have two separate cookies one set in the irule and one for default. I tried to write it but it complains as below.

01070372:3: Persistence mode (Cookie) called out in rule (irule1) requires a corresponding persistence profile for virtual server (test).

"Path shows correct. But is not matched in irule even though query is exactly for that same path, so no logs are seen for the path."

Then the switch statement must be incorrect - do you have the right case?

"Is there a way to have two separate cookies one set in the irule and one for default. "

Yes. Set a cookie based on cookie insert (give the cookie a relevant short name - I hate seeing cumbersome BigIPxxxxxxxxx cookies) and assing profile to virtual. Then your iRule will not complain when you say "persist cookie insert jj_cookie". Beware of this though; http://support.f5.com/kb/en-us/solutions/public/11000/600/sol11679.html you can get round it by creating a profile for a session cookie with the cookie name jj_cookie.

This has been resolved. Application person set the virtual directory names against the standard which is to have all lower case. In other words he set the name to use upper and lowercase.

Thanks to all that tried to help.