Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
May 07, 2012

LTM honoring Session Cookie set by another LTM

We have an application which is GTM-enabled, and has virtual servers in two different data centers on two independent LTM pairs (10.2.0). The virtuals are being load-balanced by the GTM with Round Robin. Now the application requires Cookie Persistence to be maintained across LTMs. Both virtuals use Session cookies with the "HTTP Cookie Insert" method.

 

 

Based on our testing, it seems that one LTM will honor the session cookie set by another LTM. This makes sense after I decoded the cookie and found that the value of the cookie is simply the address and port of the pool member. We have successfully combined this Cookie behavior with some Priority Activation trickery in an iRule to selectively enable SNAT when a pool member is not local to the LTM.

 

 

The question we are asking ourselves is whether or not this supported behavior, is it more of a coincidence that we can take advantage of, or is it something that we are cautioned against using?

 

config
design
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 07, 2012
    Hi SMP,

     

     

    This is expected and supported as the persistence cookie value is an encoding of the pool member IP:port. The cookie name is by default set with the pool name. As long as the pool name is the same for both LTMs this will work fine. If the pool name is different but the member addresses and ports are the same, you could create a custom cookie insert persistence profile on each LTM pair with the same custom cookie name

     

     

    http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html

     

     

    Aaron
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 17, 2012
    SMP: this is by design, and is one of the reasons why I love using this method for persistence. It's essentially offloading the persistence record to the client, which means that it's now portable across setups exactly like yours.

     

     

    Rock on, it'll work - good design work, as usual :)

     

     

    --Matt
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    May 17, 2012
    L4L7 - long time no speak. Nice to hear from you again.

    Thanks for the feedback guys. I just realized I never completed this thought. Here's where we were planning to go with this idea. We set up VIPs on each LTM pair which are configured with the same Pool names. The Pools are configured with the same members - some from each data center. The priority of the members in the LTM's internal VLAN are set higher (and equal) than the members in the remote data center. Setting the priority in this way ensures new connections are load-balanced only to the local data center under normal conditions.

    Then we apply this logic to an iRule on both VIPs:

    
when LB_SELECTED {
  if { [LB::server priority] == 0} {
    snat automap
  }
}
    When a client connection with a cookie referencing a remote pool member comes in, it seems to fire the LB_SELECTED event. So we look at the priority and only SNAT when the member is in the remote data center (i.e. has the lowest priority). We can then use GTM Round Robin load-balancing which gives us the best load distribution, without losing client Persistence.

    See any flaws with that configuration?