Forum Discussion
uie persistence cookie
Hello,
I have one VS with a pool with three servers listening on port 80.
I have to persist on a cookie from the servers.
The cookies name is "ASPSESSIONIDxxxxxxxx". The x's are changing from day to day, not from session to session. So the unique information is in the cookie a 26 character string. On this string I want to base the persistence on.
I don't know how to deal with the changing cookie names to read their content.
I hope somebody can help me.
Regards,
Marcus
- Hi,
I thought of something like this
when HTTP_RESPONSE {
set ASPID [findstr [HTTP::cookie] "ASPSESSIONID" 12]
set Cookie_Name [ASPSESSIONID][$ASPID]
persist uie [HTTP::cookie $Cookie_Name]
}
Please don't laugh, I'm a real nub on this.
Thanks,
Marcus - Does it matter if I use HTTP_REQUEST or HTTP_RESPONSE in this scenery?
schwiddy - Well, the cookie is being set by the servers, hence the use of HTTP_RESPONSE above, but theoretically the next request should have that cookie attached as well, so it shouldn't matter much in this case, I don't believe.
-Colin - OK, what about this one to check out the cookie content and build a persistence on it:
when HTTP_REQUEST {
set ASPID [findstr [HTTP::cookie names] "ASPSESSIONID" 0 20]
log local0 "ASP Cookie Name is $ASPID"
set ASP_Content [HTTP::cookie $ASPID]
log local0 "Cookie content is $ASP_Content"
persist uie $ASP_Content
}
schwiddy - Interesting. If there are multiple cookies that match, then findstr should theoretically still use the first match. I'd have to test this to see the definite results, though.
When your client says that they're getting directed incorrectly, can you check the logs to see what's going on? You might want to add some logging in the rule to see what's happening on each pass.
Colin - not sure if you solved this, but I noticed you don't set the optional timeout in your persist statement.
I believe that's what controls the update of the timeout in the session table. - Hi all,
that was a nasty one...
The iRule is fine the way it is.
It was that the traffic from the content caches reached the loadbalancer using multiple connections in one. So the BigIP didn't inspect all the packets, after the connection was initiated. So the persistence timer was never reset.
We worked around by creating a OneConnect Profile using a /32 subnet mask.
Regards,
Marcus
