Forum Discussion
AltostratusCookie persistence and source address fallback
I wonder what will be result of such setup:
- LB set to Round Robin
- Default Persistence Profile: Cookie (Cookie Insert)
- Fallback Persistence Profile: Source Address
- Source IP same for all requests (SNATed)
My assumption is:
- First new TCP connection established, no cookie present
- Fallback Persistence used, no Persistence Record (PR) found
- No persistence is applied because none exist so connection will be directed to first member
- What will happen then? Persistence Record for source IP will be created pointing to first server?
- In HTTP response cookie is inserted pointing to first pool member
- Then second connection from the same IP comes, assuming that PR was created and did not time out then LB will be ignored and connection will be directed to first server
- In HTTP response again cookie pointing to first server will be inserted
- Then all returning connections (with cookies set) will be directed to first server, LB in fact will not be used, except for situation when there is enough period of inactivity between connections to allow PR to expire, but will then new connection be send to second server according to RR or not necessarily?
Is above correct?
Piotr
You are correct when putting Cookie and Source Persist together. If there is a persist record it will go to that server and cluster all the clients that share the same IP to the same server.
19 Replies
You are correct when putting Cookie and Source Persist together. If there is a persist record it will go to that server and cluster all the clients that share the same IP to the same server.
dragonflymrCirrostratus
Thanks, good to have confirmation from experienced F5'ers Piotr
gsharriPiotr, If the clients have a persistence cookie then the source address records will not be used. LTM will attempt to match clients with no cookie with a source address persistence record and then insert a cookie into the response. Note that the source addr persistence record will be created using the client-side source address not the server-side snat source addr.
keshav_163381Nimbostratus
Yes....Because Persistence table check first before doing the SNAT on egress interface
kbksTell me please, with the same settings.
The BIGipServer_keycloak cookie is created. When i am using different use profiles (firefox) i have the same cookie for all of them. Can i somehow get the situation, that each session from different browser/profile (and also private session) will have different cookie assigned?When using different browsers you will have the same cookie name of "BIGipServer_keycloak",
but the cookie values themselves should be different. Is this not the case?Edited. Cookie values can be the same.
- kbks
My values are not different, they are the same. And i think, they should be different. (i am using different firefox user profiles).
- kbks
Also, what i could do is to set up persistance options with cmd line, it was not saving settings from gui.
I used this command to check what are the settings :tmsh show running-config ltm virtual vs_httpsand this command to set it ip like on the screenshots:
tmsh modify ltm virtual vs_https persist replace-all-with { Keycloak_cookies { default yes } keycloak_pers_sourceaddr { default no } }The result now is like this:
persist { Keycloak_cookies { default yes } keycloak_pers_sourceaddr { default no } }but before it was like this:
persist { Keycloak_cookies { default yes } }Is this normal behaviour? I understand this is correct? now in GUI it looks like this:
You have added two different persistence profiles to the virtual server, "Keycloak_cookies" and "keycloak_pers_sourceaddr". Since "Keycloak_cookies" is set as the default persistence profile (default yes), then this will always be used. "keycloak_pers_sourceaddr" which is set to "default no" will never be used unless you call it using an iRule. Is this the behaviour that you wanted?
If not, then your intention may have instead been to have cookie persistence as the primary persistence method and source IP persistence as the fallback persistence. This would be configured like so:tmsh modify ltm virtual vs_https persist replace-all-with { Keycloak_cookies { default yes } } fallback-persistence keycloak_pers_sourceaddr- kbks
and this is ok? It looks like only persistance profile is used and fallback not exists:
persist { Keycloak_cookies { default yes } }
