Forum Discussion

Austin_Geraci's avatar
Austin_Geraci
Icon for MVP rankMVP
Mar 30, 2011

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!

application delivery
dev
devops
iRules
  • Michael_Yates's avatar
    Michael_Yates
    Icon for Nimbostratus rankNimbostratus
    Mar 30, 2011
    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?
  • Austin_Geraci's avatar
    Austin_Geraci
    Icon for MVP rankMVP
    Mar 30, 2011
    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..
  • Austin_Geraci's avatar
    Austin_Geraci
    Icon for MVP rankMVP
    Mar 30, 2011
    @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_Yates's avatar
    Michael_Yates
    Icon for Nimbostratus rankNimbostratus
    Mar 30, 2011
    Interesting.

     

     

    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.

     

  • Austin_Geraci's avatar
    Austin_Geraci
    Icon for MVP rankMVP
    Mar 30, 2011
    @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 ;)