Forum Discussion
Kai_Wilke
Feb 12, 2016MVP
Hi Akhilesh,
the command
[persist uie cookie]
does not set/read any kind of HTTP cookies, its more or less just tracking your session persistence using the static plain-text value "cookie
".
To understand the
[persist uie]
behavior, you have to read the command like [persist uie UNIVERSAL_TXT_STRING_TO_TRACK]
, where the string can be any kind of information the user would provide while requesting information. It could be a source IP, it could be an URI, it could be an HTTP-Header or HTTP-Cookie value the user is providing on each single request. Well, in your specific case, you're not using any provided data, instead your using the fixed value of "cookie" for every client causing to team every session to the same pool_member...
To track your users based on a HTTP-Cookie value using
[persist uie]
your need to monitor the HTTP_REQUEST
for the desired HTTP-Cookie value. If the value is present, then [persist uie $cookie_value]
the session. If the user is not providing the desired cookie, then perform a regular load-balacing decission (e.g. Round-Robin) and monitor the HTTP_RESPONSE
if the server sets the cookie. As soon the server is setting the Cookie, issue a [persist add uie $cookie_value]
to team the cookie value to the current pool_member selection. The very next REQUEST of the user would then provide the $cookie_value
which can be used to [persist uie $cookie_value]
the request to the last pool_member selection.
Alternativly you could also use the
[persist cookie insert MY_LB_COOKIE_NAME]
command, to let the F5 insert an auto-generated cookie used exclusivly for persisting the session. Its a much easier syntax and does not require any well known application cookies to be in place. In addition to that its completely stateless and therefor doesn't consume session table memory to store the persitence information...
Cheers, Kai