LTM honoring Session Cookie set by another LTM

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

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

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?