Forum Discussion
NimbostratusPriority Group and session persistence
Hi,
I've tried to find an answer to this but so far unable. Hoping someone here can point in the right direction.
Setup: HA-pair (Active-Active) with two traffic groups (tg1 and tg2). tg1 has Big-IP1 as primary, tg2 Big-IP2 as primary. VIP1 is in tg1, VIP2 in tg2. VIP1 has pooltg1, VIP2 pooltg2. pooltg1 has four members (member1, member2, member3, member4), pooltg2 has the same members as pooltg1.
In pooltg1 member1 and member2 have priority2, and the other two have priority1. In pooltg2 member3 and member4 have priority2, and the other two have priority1.
Question: What takes precedence, priority or session persistence ? The problem is that we see users using iPhone/Android often switch between the two VIPs, and that way they loose they're initial connection. My understanding was that whatever vip/traffic group you got into, you should be directed to the correct member cause of the persistence. DNS resolves to the two vip's using RR.
3 Replies
shaggyAre you using GTM to RR between the virtual addresses, or is it simply DNS RR? DNS RR is not persistent. Once a user hits a virtual server, persistence will take precedence over priority.
Are the members in both pools identical, and what type of persistence is in use? You may be able to share persistence entries between the two virtual servers and mirror those records between the HA-pair (if necessary depending on the persistence type).
JimTThanks for reply shaggy. At the moment we are using DNS RR. GTM is on it's way.
The members are identical, and we are using source-addr persistence with Persistence mirroring.
The problem here is that when a user first hits, let's say vip1, everything seems ok at first(At first hit the user gets a jsessionid cookie from the application). The user then hits a login button and gets redirected to an authentication site, logs in and gets redirected back to the main site. And here is the problem...Sometimes the user gets back to mainsite logged in, other times he have to log in again. The traces shows that when it fails, the redirect back to the mainsite goes through the other vip (vip2). This is where I'm not sure why the persistence doesn't route the connection back to the "original" member.
- shaggy
source-address persistence ties a source-ip to a virtual-address to a pool-member-IP, so persistence is not shared between vips/pools by default. Why don't you use the same pool for both virtual servers, and create a persistence profile that has "Match Across Pools" enabled? or better yet, share the same pool between the two virtual servers, and use cookie persistence instead of source-address as cookie persistence keys off of the LTM pool name by default.
