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...
Nikoolayy1
MVP
MVPMaybe 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:
miodasAltocumulus
AltocumulusHi
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
Hello, Did you manage to solve the issue?