Forum Discussion
miodas
Altocumulus
AltocumulusPersistence source addr / cookie, client->vip1->pool1->vip2->2pool
Hello Everyone
Scenario:
Client is connecting to VIP 1 ( with 2 pool members ) new connection from one of the pool members is set up to vip2-pool2 (with 2 pool members )
in short client->VIP1-pool1->VIP2->pool2
VIPs are https
VIP 1 default persistence - source address / no fallback
VIP 2 default persistence - cookie/fallback source address
How persistence will work in a scenario like this?
I am not that good with cookie stuff on F5 but my understanding is that IF only servers from VIP 1 are connecting to VIP2 default cookie persistence shouldn't work right?
- Nikoolayy1
MVP
Maybe check if the the first VIP is removing the cookie of the second VIP with an irule logging:
https://support.f5.com/csp/article/K55131641
https://community.f5.com/t5/technical-articles/the101-logging-and-comments/ta-p/280832
Maybe if you change the cookie name that the first VIP inserts this way the first VIP may not remove it if it is the default name:
https://support.f5.com/csp/article/K83419154
Have you also reviewed using One Connect Profile K7964 and for debug of cookie K5714?
Also when you were using source address persistance on the Second VIP did see what is the Load Balancing method on the first VIP? Also because there could be a proxy before the first VIP this could explain why the first VIP may select just one pool member more than the other and the the source address persistance of the second VIP may again affect you. You may also test changing the persistance of the first VIP if does SSL decryption to another cookie persistance with a cookie with different name of SSL persistance if there is no decryption:
miodasHi
On both VIPs there is a round-robin, the load is distributed ok but when it comes to 2nd VIP problem starts because of source persistence VIP1 has 2 members in the pool and only 2 members are being utilized from VIP2.
Thank you for links i will take a look- Nikoolayy1
Ok, please test and mention the results except the things I already mentioned, you can also test CARP persistance on the second VIP. As the example below shows using the XFF header that the first VIP can inject, so that the persistance to be based on real client IP addresses rather than the first VIP pool members.
- Nikoolayy1
The cookie persistence is for VIP2 to select between the members in pool 2 , so it shouldn't care about if the source is the first or second member of pool 1 (the pool for VIP1) and work. Still read this just in case:
- miodas
Hi
to be exact it looks like that
client -> ( with public IP )->NAT->172.25.241.11vip1 -> (172.25.200.13 , 172.25.200.22) -> 172.25.242.32vip2 -> 172.25.119.18/19/29/30
When i tested it with cookie persistence on VIP2 user was ending up on one of the 4 servers in pool of VIP2
wit each website refresh he was on a different node.
Problem is that VIP 1 has only 2 pool members that are initiating a connection to VIP 2
and with source persistence traffic is not distributed to all 4 pool members from VIP2
Customer wants to have persistence and even distribution between 4 servers from VIP2
The easy way would be to just add 2 additional nodes to VIP1 but is there any other way to make that work with 2 nodes ?
