Forum Discussion
cookie persistence profiles in conjunction with an iRule
I'm having an issue with cookie persistence when passing through multiple load balancers, that aside, can someone please verify a couple things for me?
scenario 1
-your_cookie_name is a persistence profile with the general profile name of "your_cookie_name", cookie mode insert and a cookie name of "my_cookie"
profile persist your_cookie_name {
defaults from cookie
mode cookie
cookie mode insert
cookie name "my_cookie"-Is the iRule command "persist cookie insert your_cookie_name" designed to call the profile named "your_cookie_name" and insert a cookie named "my_cookie" or will it insert a cookie named "your_cookie_name"?
Whenever I've used cookie insert I never used the "cookie name" feature.. and it always defaulted to the general name... I'm using it now and I'm seeing both at pool1.. so it looks like a bug.. I would think it would use the custom name within the profile as you can't call the command in the iRule without a profile attached to the VS.
scenario2
rule my_irule {
when HTTP_REQUEST {
set uri [string tolower [HTTP::uri]]
if { [class match [HTTP::uri] starts_with myclass] } {
pool pool1
} else {
pool pool2
persist cookie insert your_cookie_name-A cookie persistence profile and an iRule are assigned to a VS. The iRule will route traffic to a pool on specific URIs, else it sends to another pool and uses "persist cookie insert your_cookie_name". Will a cookie be sent when matching the first condition because a persistence profile is assigned to the VS in general, even though the command is not being called within that portion of the iRule?
Thanks!
5 Replies
Michael_YatesNimbostratus
From my experience if you have a Virtual Server that has multiple pools the BigIP will give you a persistence cookie for each pool that your traffic is being routed to.
We keep our static content on a different set of servers, so anything that's "/images" goes to one pool and anything that's "/app" goes to another. You will be issued a cookie for each pool in the format of:
BIGipServer=HashedServerIPAddress.HashedServerPortNumber.0000
You can decipher the hash by looking at "SOL6917: Overview of BIG-IP persistence cookie encoding" to see which server in each pool you are going to.
We also have multiple levels of BigIP's and the others just ignore a cookie that isn't for them (although I do wonder what would happen if you had identical pool names on different load balancers).
I guess this leads to my question of, why set a persistence cookie yourself via an iRule when you can use the default functionality of the BigIP? Is there a special circumstance where you have to?- Okay figured out what was going on here, in short I needed to shut of persistence before it was sent to pool1. Even if you're not calling persistence in your iRule the default persistence profile will be applied, so it should look like this:
rule myrule { when HTTP_REQUEST { set uri [string tolower [HTTP::uri]] if { [class match [HTTP::uri] starts_with myclass] } { persist none pool pool1 [code/] Additionally, the "persist cookie insert your_cookie_name" was inserting the literal name "your_cookie_name" instead of refrencing the cookie name within the profile.. - @Mike We didn't need to set the cookie name via the iRule, and actually the second part of the iRule was mucking things up because it was inserting the exact name and not the cookie name within the profile..
The reason we needed a custom cookie name is we need to maintain persistence across multiple load balancers with the same pool name & members. - Michael_YatesInteresting.
Thanks for the explanation :-)
We haven't had to do this in my environment yet. Looks like something that might be interesting to create and test though. - @Mike, yeah I've used that solution many of times, I actually had to reverse the hash backin this instance and found the pool member to be pool1, again, I neede the persist none in my iRule
Another thing I should mention is I had to decrypt the packet captures to read the cookies since everything was in SSL.
Someone should add the -H option to the sol10209: Overview of packet tracing with the ssldump utility
http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html?sr=13600230
You need that the -H option to Print the full SSL packet header, which contain the cookie(s).
At the very least it's indexed here now ;)
