Forum Discussion

JorenC's avatar
JorenC
Icon for Nimbostratus rankNimbostratus
Feb 09, 2017

Multiple jsessionid cookies on VS

Hi all,

We are in the process of replacing our IBM webseal by F5. Basically we have multiple Websphere containers behind our F5 with APM. We use one landing VS where we check uri, ACL, some custom logic in irule and then forward the client accrdingly. If all is OK we will send them to the correct vs.

Current setup is:

 

client > F5 > VS-to-cherry-pick-APM-enabled > VS > node-1 (websphere) [jsessionid-1]
                                            > VS > node-2 (websphere) [jsessionid-2]
                                            > VS > node-n (websphere) [jsessionid-n]

 

All these containers rely on their own JSESSIONID cookie for session management.

In order to differentiate these cookies between the containers the webseal uses a cookiejar. With this it can differentiate the inserted cookie based on container selected (see square brackets in example above). Is there a similar technology available on F5 or is this something that should be coded in an irule?

 

Thanks in advance,

 

Joren

 

devops
iRules
jsessionid
webseal
websphere
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Feb 09, 2017

    Hi Joren,

     

    how does the "cherry-pick" chooses the backend VS instances? By HTTP::path, by HTTP::host, etc.?

     

    Cheers, Kai

     

  • JorenC's avatar
    JorenC
    Icon for Nimbostratus rankNimbostratus
    Feb 09, 2017

    Hi Kai,

     

    The cherry picking is done in a custom iRule. In this iRule we will check the HTTP::uri, cross-match it with our APM ACL and allow the user to be redirected to another 'backend' VS via the virtual command in the iRule. Since all requests will be located on the same baseURL *

     

    Thanks,

     

    Joren

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Feb 09, 2017

    Hi Joren,

    how about using an iRule that prefixes each outgoing jsession cookie with POOL_${CurrentlySelectedPoolName}_* and then removes the prefix in the incomming direction.

     

    - Outgoing direction:
    - Original Header   : "Set-Cookie:" "jsession=abc; secure; path=/"
    - Translated Header : "Set-Cookie:" "POOL_YOURPOOL1_jsession=abc; secure; path=/"

- Incomming direction:
    - Original Header   : "Cookie:" "POOL_YOURPOOL1_jsession=abc;POOL_YOURPOOL2_jsession=abc;POOL_YOURPOOL3_jsession=abc"
    - Translated Header : "Cookie:" "jsession=abc;POOL_YOURPOOL2_jsession=abc;POOL_YOURPOOL3_jsession=abc"

     

    The required iRule code to translate/untranslate the cookie names will look like this...

     

    when HTTP_REQUEST {
    if { [HTTP::header value "Cookie"] ne "" } then {
        HTTP::header replace "Cookie" [string map [list "POOL_[URI::basename [LB::server pool]]_" ""] [HTTP::header value "Cookie"]]
    }
}
when HTTP_RESPONSE {
    if { [set cookie_values [HTTP::header values "Set-Cookie"]] ne "" } then {
        HTTP::header remove "Set-Cookie"
        foreach cookie $cookie_values {
            if { [string tolower $cookie] starts_with "jsession" } then {
                HTTP::header insert "Set-Cookie" "POOL_[URI::basename [LB::server pool]]_$cookie"
            } else {
                HTTP::header insert "Set-Cookie" $cookie
            }
        }
    }
}

     

    Note: You have to apply the provided iRule on the individual backend-VS objects, so that the currrently selected pool name can be resolved by [URI::basename [LB::server pool]]. But depending on your detailed requirement and the configuration of the frontside VS (e.g. HTTP-Profile enabled) you could rewrite the iRule to use a different text-string as differentiator based on whatever information is feasible for you...

    Cheers, Kai