Forum Discussion
Bruce_Hampton_1
Nimbostratus
Nimbostratus1 VIP < Multiple pools
I have a fun little situation where I am terminating SSL, parsing the URI and picking a pool. Easy enuf... but now is where I could use a little help *grin*
I want to be able to switch back and forth between the pools at will ( based on URI ) and have 2 separate persistence cookies to keep me on the chosen member.
I can switch pools just fine, and I can persist just fine during the first time in to each pool. The challenge comes in when I go from pool_HTTP_Online to pool_PrintLastYear back to pool_HTTP_Online. The cookie is present but doest not appear to be honored.
Any help would be appreciated.
=====================================================
rule irule_persist_Multiple_Pools {
when HTTP_REQUEST {
if {[HTTP::uri] contains "s_online_2004"} {
persist cookie insert LastYear 31622400
pool pool_PrintLastYear
}
else {
persist cookie insert TAOL 31622400
pool pool_HTTP_Online
}
}
}
virtual VIP_Online_CLEAR {
destination 172.16.1.10:http
ip protocol tcp
profile oneconnect pf_http_Online tcp
persist pf_OL_05_Final
pool pool_HTTP_Online
rule irule_persist_Multiple_Pools
}
11 Replies
- Create a OneConnect profile with mask of 255.255.255.255 and apply it to the virtual server, and you should be good to go.
(Without OneConnect enabled, only the first request in a Keep-Alive connection is parsed for persistence data.)
HTH
/deb 
Bruce_Hampton_1Thank you for the reply.
Already have the one connect modified to a 32 bit netmask.... it's as if it is ignoring my custom cookies. But I can see them being sent to the browser.
profile oneconnect oneconnect {
source mask 255.255.255.255
max size 10000
max age 86400
max reuse 1000
idle timeout override disable
}- ah, I missed that, sorry.
I notice that you have a default persistence profile configured on the virtual as well as calling the 2 different cookie persistence profiles from within your iRule. Have you tried deleting the default persistence profile and relying on the iRule logic alone for persistence?
/deb - Have you tried removing the first cookie before you add the second, and vice versa?
It'd be pretty trivial to check to see if cookieA was present before adding cookieB, and if so, remove it, add cookieB, and persist using that info.
This might clear up the issue with your cookies not being honored.
Colin - Bruce_Hampton_1Colin and Deb, thanks for the replies.
I need to keep 2 cookies in place one for persistence within pool 1 and one for persistence within pool 2. Are you suggesting I remove the one that is being stuck in by the default cookie peristence profile?
Bruce 
BASLI_amine_788Hi,
I am exactely in the same case as you! I need to use persistence for multiples pools using distinguishes cookies
Did you find a solution for this problem ?
Thank you- Eric_Grepps_264We are doing this very same thing using the default cookie persistance profile. If you do not specify a cookie name, the BigIP creates it own name for each pool.
For example I use this iRule to direct traffic based on the root directory:
when HTTP_REQUEST {
switch [getfield [string tolower [HTTP::uri]] "/" 2] {
app1 { pool pool_app1 }
app2 { pool pool_app2 }
app3 { pool pool_app3}
}
}
After visiting all 3 pools in the same broswer session I get the following cookies:
BIGipServerpool_app1
BIGipServerpool_app2
BIGipServerpool_app3
The BigIP uses the value stored in the respective cookie to direct the traffic to the correct pool.
I also verified that this works when we create our own persistance profile of type cookie, parent = cookie, method = HTTP Cookie Insert, Cookie Name = and Expiration Session Cookie checked.
/Eric Grepps - Bruce_Hampton_1Thanks for your input Eric. I was also able to make this work; the *trick* for me was to NOT name the cookie in the profile, and remove the additional cookies from the rule. I have no clue why it would care what the cookie name is - but once I defaulted to the system supplied name - it did exactly as I wanted and as Eric suggested he was doing.
Hope this helps.
Bruce - Eric_Grepps_264If you specify the name of the cookie, then it will always use that cookie name for each pool. So when you jump between pools the cookie will be overwritten since it is the same name. By not specifying the name the BigIp will write a different cookie for each pool.
There are some simple tools out there so you can view the cookies that are being set from the broswer side. I use the free firefox extension called LiveHTTPHeaders and a windows app called HTTP Inspector which costs money. - Bruce_Hampton_1Yes I have lots of those tools... funny part was that I was specifying different cookie names for each pool. But somehow it wasn't performing that way. Thanks once again for all the help.
