SOL9800: Dokumentation Bug?

Hi Folks,

SOL9800 states the following...

"With a OneConnect profile applied, the server-side connection is always detached upon completion of the server response, and the default pool selection is reset for each request to match the default pool configured on the virtual server. As a result, pool reselection using an iRule applied to a OneConnect virtual server operates as expected:

• Requests matching the pool selection conditions coded in the iRule are always sent to the indicated pool.
• Requests not matching any pool selection condition in the iRule are always sent to the default pool configured on the virtual server, regardless of whether a pool was already selected for a previous request on the same connection."

Link: https://support.f5.com/kb/en-us/solutions/public/9000/800/sol9800.html

While using TMOS v12 this behavior can not be observed. The pool selection wouldn't get reverted to match the default pool on each subsequent request.

iRule used to repro the behavior

when CLIENT_ACCEPTED {
    log -noname local0.debug "CLIENT_ACCEPTED: Virtual Server Default Pool = [LB::server pool]"
    log -noname local0.debug "CLIENT_ACCEPTED: OneConntect Profile = [PROFILE::exists oneconnect]"
    set keep_alive 0

}
when HTTP_REQUEST {
    log -noname local0.debug "HTTP_REQUEST: Connection Keep-Alive = $keep_alive"
    log -noname local0.debug "HTTP_REQUEST: Current Pool Selection = [LB::server pool]"
    if { not [info exists pool_selected] } then {
        pool www.itacs.de
        log -noname local0.debug "HTTP_REQUEST: New Pool Selection = [LB::server pool]"
        set pool_selected 1
    }
    set keep_alive 1
}

Log output for OneConnect enabled Virtual Servers

Wed Feb 3 11:27:33 CET 2016  debug   f5-02   tmm[10466]      CLIENT_ACCEPTED: Virtual Server Default Pool = /Common/default_pool
Wed Feb 3 11:27:33 CET 2016  debug   f5-02   tmm[10466]      CLIENT_ACCEPTED: OneConntect Profile = 1
Wed Feb 3 11:27:35 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 0
Wed Feb 3 11:27:35 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/default_pool
Wed Feb 3 11:27:35 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: New Pool Selection = /Common/other_pool
Wed Feb 3 11:27:37 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 1
Wed Feb 3 11:27:37 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/other_pool
Wed Feb 3 11:27:38 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 1
Wed Feb 3 11:27:38 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/other_pool

Log output for OneConnect disabled Virtual Servers

Wed Feb 3 11:25:21 CET 2016  debug   f5-02   tmm[10466]      CLIENT_ACCEPTED: Virtual Server Default Pool = /Common/default_pool
Wed Feb 3 11:25:21 CET 2016  debug   f5-02   tmm[10466]      CLIENT_ACCEPTED: OneConntect Profile = 0
Wed Feb 3 11:25:23 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 0
Wed Feb 3 11:25:23 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/default_pool
Wed Feb 3 11:25:23 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: New Pool Selection = /Common/other_pool
Wed Feb 3 11:25:25 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 1
Wed Feb 3 11:25:25 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/other_pool
Wed Feb 3 11:25:26 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Connection Keep-Alive = 1
Wed Feb 3 11:25:26 CET 2016  debug   f5-02   tmm[10466]      HTTP_REQUEST: Current Pool Selection = /Common/other_pool

Note: I realy love the observed behavior for OneConnect enabled Vitual Servers! The observed behavior allows me to save ~10000 clicks for every keep-alived HTTP request, by implementing a custom flow mechanism. The mentioned flow mechanism would only select a new pool when needed (amongst other per-connection settings/variables), but not reapply an already selected pool on each subsequent request. So if you gonna raise a Bugfix or DCR to match SOL9800, then please make sure the behavior can be controlled by SYS-DB options. Or at least control the behavior this way, that when no default pool is specified, then it should not revert back to nothing. Thanks... 😉

Cheers, Kai