Forum Discussion
Piotr_Lewandows
Altostratus
AltostratusFallback Persistence Profile - how it works
Hi,
I don't know if this is bug or correct behavior - tested on 11.2.0
Setup:
-
VS with
- Default Persistence Profile: cookie insert
- Fallback Persistence Profile: source address
Result:
-
First request from client (without cookie):
- Set-Cookie header in response setting BIGipServer... cookie
- Persistence Record (PR) created - makes sense because there was no cookie in client request
-
Second request from client
- Cookie send in request
- PR timeout refreshed - could be OK as PR exists matching client IP but because Cookie is provided why it's used?
-
Third request - after PR was manually deleted
- Cookie send in request
- PR record created
Why PR is recreated when cookie exists? Which persistence is in fact used - cookie or source address?
Piotr
dragonflymrCirrostratus
OK, answering own question. After test it looks like cookie value is used for persistence decision, even if PR is refreshed.
After some thinking it seems logical :-) To be able to use Fallback Persistence, PR has to exist so it has to be created and maintained in parallel with Default Persistence.
Or I am wrong here?
Piotr
Stanislas_Piro2Cumulonimbus
Hi,
fallback persistence profile allow you to manage another persistence profile if the first fails.
Example :
- default Persistence : source address (not synchronized between cluster members)
- fallback persistence : cookie
when cluster failover, second member does not have any record and cookie persistence will work.
another example :
- default Persistence : cookie
- fallback persistence : source address (not synchronized between cluster members)
you browse with internet explorer and the browser crash (Yes, it happens more ofter than you want :) )
you restart your browser without cookie and you are balanced to the same server than previously