I have a problem with F5 loadbalancer and session timeout in ASP application. We have F5 in out company for few days Since then, there is a problem with session timeout. ASP app has 30min timeout set but keeps logging of already after few minutes. This phenomenon didn't occur with Windows loadbalancer.
I guess the default Idle timeout on your F5 is 300 seconds for TCP connections. If you want to set a higher value for this, have a look in your tcp profile.
Hope this helps,
You're right, http is stateless and tcp is stateful.
You said the issues occur since you've changed from a Microsoft product to a F5, so I would search here for the differences. It's not new to me that Microsoft has it's own interpretation of RFCs.
If the problem is reproducible, I would recommend a Wireshark trace on the app server and client and compare them. Maybe you need to do further investigation on the "middle-ware" (like the F5 or Firewall) if the traces don't corelate.
I think this is seen as a new request from the F5 and a new load balancing decision is made. This would mean that you might randomly (depending on the load balancing method) fall into this issue.
Are you using any persistence profile? If you use persistence based on client IP addresses this problem shouldn't appear. However, if you have loads of client requests with the same IP (like clients behind a proxy or CDN), then I made good experiences with granting a session cookie.
Let me know if this helps,
I agree with Manuel,
Along with persistence you can also check the TCP protocol client and server profiles.
you can create a custom TCP profile with "Reset On Timeout" disabled, idle timeout to 1800 and apply on virtual server Protocol Profile (Client) and Protocol Profile (Server)
Awesome! If you need to have more control, you can write an iRule and merge it with a universal persistence profile.
There would be an impact, if the client browser does not support cookies. However you can bypass this with a fallback persistence profile (like based on source IP, as Dan mentioned)
Basically I prefer the use of session cookies from my experience.
HTTP is stateless protocol in application layer. Is problem in idle Time TCP? I'm not sure.
Automatic logout occurs in different time interval < session timeout ASP app.
How I can verify this problem on the app server? Maybe Wireshark?
I installed WireShark on the application server's. I observer below situation:
request1 (logging) -> AppServer1 (OK)
request2 (search product) -> AppServer1 (OK)
request3 (product details) -> AppServer1 (OK)
--------- Delay (more than 180sec)
request4 -> AppServer2 and logout.....
Why request is redirect on AppServer2??
I changed idle time for persistence based on client ip on 1800 sec (default 180sec) and is better :).
Is it possible that change persistance on cookie has an impact on the work user? I will change this option on production environment.
I am having same issue, Load balancing is configured as Round robin, TCP connection profile time out is default which mean it is 1800 sec.
I also have cookie based persistence. Don't have fallback persistence.
Do I need to configure fallback source address persistence ? Appreciate if anyone could brief me about source persistence.
Kindly consider my request to confirm this.
what exactly is your issue? If the sessions time out on the F5 before they do in the application you just need to create a custom TCP connection profile with the corresponding timeout values for TCP connections.
The source address persistence creates a persistence record for each client IP address. This means, when the same client IP is trying to access the same application within a short time range, he will get loadbalanced to the same node. Basically as a fallback for cookie persistence this would only affect browsers/applications who won't accept cookies, so this might not be related to your issue.
I have published one application from F5 with URI redirection. On the same VIP we have configured cookie persistence. From last few days end users are facing session timeout . I mean user session getting timed out, they unable to complete certain steps which are mandatory for the application. For example you can consider Registration on website, users are able to put name, email id, mobile no but unable to put driving licence number at the portal, which is also one of the mandatory step for that specific application.
In my previous comment I was asking you, Do I need to configure fallback persistence as source address ?
Hope i have clarified your doubts.
In our F5, customized TCP profile already created, it is also properly applied to respective VIP and time out kept as default which mean timeout is 1800 sec. Am i right ?
I don't think that a fallback persistence profile will help, as clients will probably already have a persistence record based on the cookie. In this case that change would have no effect.
I've just checked: the default idle timeout from the TCP profile is 300 seconds. If this service has a higher idle timeout, I can think about two solutions:
x) get the application to send TCP keepalives regularly, or
x) set the idle timeout value to, e.g. 1800 seconds (or higher)
Probably the second solutions fits better for you :-)