For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

dragonflymr's avatar
dragonflymr
Icon for Cirrostratus rankCirrostratus
May 14, 2015

ASP.NET persistence vs BIG-IP cookie

Hi, I looked at the post about ASP cookie based persistence and it seems to be quite easy and obvious. What bothers me is what is advantage or rather when it makes more sense to use for example ASP...
application delivery
deployment
design
LTM
TMOS
Max_Q_factor's avatar
Max_Q_factor
Icon for Cirrocumulus rankCirrocumulus
May 14, 2015

Those questions may actually be related. Each ASP.net application can set it's own SessionId. say you have 1 application deployed in https://www.site.com/documents and another deployed in https://www.site.com/hr you may end up with multiple ASP.net cookies which could lead to persistence issues. Also each ASP.net application can remove or change the cookies so you may have one application that removes the SessionId, it will be regenerated for the other applications but that may cause perisstance issues.

 

If you are using a traffic policy (or an iRule like proxy pass) to load balance to different pools via url path or other criteria the F5 cookie option is also nice because F5 will insert a new cookie for each pool name - SOL6917: Overview of BIG-IP persistence cookie encoding

 

If I were to choose, I would always use the F5 cookie insert because it is a known entity and not externally controlled. On the other hand, it is nice to know when a session no longer needs to be persistent because the SessionId has been removed since the cookie insert is session based.

 

Max_Q_factor's avatar
Max_Q_factor
Icon for Cirrocumulus rankCirrocumulus
May 14, 2015
The 2 cookie values being the same may be different users - see here - https://stackoverflow.com/questions/2448720/different-users-get-the-same-cookie-value-in-aspxanonymous The cookie timeouts are up to the application owners to set or modify. As far as what type of persistence I would use on a given application I typically use this line of thoughts: Does the application require new layer 4 connections to go to the same host if so: * Does the application have an LTM application layer profile to track it (like FTP, SIP, etc.) if so, use that and no persistence should be required * Is the Application HTTP based (and if encrypted can I decrypt it?) if so I typically use cookie insert, with source ip address as a backup * Is there some other type of object or offset in a request I can use to indicate a session inside the application request to make a decision, like part of a SQL update statement, FQDN, E.164, etc.