Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Timeout settings

Hello,

We have notices that it seems that http sessions appear to timeout more quickly when using the f5 than when using a direct connection to the server. I have done my own testing and have seen that side by side, a connection utilizing the alias that passes through the f5 did in fact timeout before another browser session that I had where I logged in directly using the server hostname (and with a different userID to make sure that the sessions were completely separate).

Here is the error:

500 Internal Server Error
SAP J2EE Engine/7.00

The Web Dynpro Application 'WebUI' has expired. Restart the application using the Refresh button or via the following link WebUI.
Details: No details available

Again I tested this side by side with and without the f5, so I do not believe it is an application setting.

I am sure there is a simple setting on the f5 that can address this, but not being an f5 administrator, I will need your help to know what to ask for.

Along the same lines, we have also seen that when making a large number (50 to 100) of web service calls through the f5 at the same time, some of them will not execute successfully, as opposed to executing the calls using the hostname of an application server where all of the calls are successful. I was thinking this may be some kind of timeout on the f5 side as well.

These are two completely separate issues, but I would appreciate any advice on either.

Thanks,

Brian
1
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Brian, this sounds like something that support would have a much better chance at solving for you than the community. I'd love to know how the Virtual Server is configured, whether there is cookie persistence (or other type of persistence) and what some of the other settings are like. The 500 Internal Server Error doesn't appear to me to be a timeout, so I'm a bit confused at what you mean by timeout.

Can you describe what happens? Are you just browsing inside the portal after being authenticated and then suddenly you receive a 500 Error? How many servers are in the pool behind the virtual? Do you get 500 errors even if you go to each instance on each server directly?


0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Nojan,

Thanks for the quick response. We use source address affinity currently. I don't have any access to the f5, but I can tell you that the network guys used the documentation in the f5 for SAP in SOA guide.

I'm calling it a timeout because it only occurs if I leave the session idle for a certain period of time (about 10 minutes is my best guess). If I open two browser sessions, one using f5 and one direct to the app server and navigate to the same place in both, logged on as separate users, then leave them both idle for 10 minutes, when i come back and click on a link, in the direct session, it goes to that link. When I click a link in the f5 session, I get the error above. It seems to be basically expiring my f5 session more quickly than it expires my direct session. Perhaps there is some kind of keepalive setting on the f5. We typically have two physical servers in the pool for each virtual server. I only get the 500 errors when using the f5, not when using the hostname of the instance in the URL.

Thanks,

Brian
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Cookie persistence should be the primary with source address as a fallback. Hopefully that's how it's setup.

When you leave a session idle for 10 minutes, the TCP connections involved are closed long before that, by your browser if not by the server. Session persistence is preserved through cookies assigned by SAP. It sounds to me like the cookie is not being properly handled , so I would check your session persistence setup under the Virtual Server in the BIG IP.

A way you can verify this is to use a web browser plugin, such as Firebug or HTTPWatch (paid version) to look at your cookies going through the BIG-IP and going direct to the server, and compare the cookies to see if there are any differences.

Without knowing more about your configuration, I would focus on the cookies as the source of the issue.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Nojan,

I setup a similar scenario utilizing firbug with firecookie enabled.

Browser1: http://<SID>.company.com:<port>/... - this is the URL utilizing the DNS alias that the f5 BIG IP listens on

Browser2: http://<appserver>.company.com:<port>/... - this is the URL directly to the app server

I can see that on Browser1, when left idle for 10 minutes then clicking a link, the SAP cookie (saplb_*) changed values to a different J2EE instance and server node and displayed the 500 error.

On Browser2, when left idle for 10 minutes then clicking a link, the SAP cookie (saplb_*) remained the same value and worked correctly displaying the results of the link.

I know that source address affinity was selected as the primary persistence on the BIG IP. Looking at the guide, I see that Cookie persistence is recommended as the primary and source as the fallback. Unfortunately these settings were chose before I came across this guide myself. Do you think changing it to cookie persistence as primary could resolve the problem?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
You should change the persistence to cookie and give it a try, but there are still a number of other variables and other questions I have about your environment that only a support case would properly gather.

While I still encourage you to open a case, let's see how the cookie change goes, if you can make that change without impacting your environment (there should be no issues, but you should take the proper precautions if this is a production system. e.g, Do the work during a maintenance window if necessary).
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I've sent a request to one of our network team members to implement the change in a Sandbox system.

Thanks for the help,

Brian
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Nojan,

So far testing has proven positive except in one case. We currently do use an iRule to switch from http to https and go from port 80 to port 50601. So, if I type in http://<SID>.company.com, I automatically get redirected to https://<SID>.company.com:50601 so that I can use SSL and present a PKI certificate. However, the network admin has configured cookie persistence as the primary with source_address as the fallback on port 80 and port 50600 (also http), but says he cannot for 50601 because "A HTTP profile did not work with the cookie persistence on the VIP for the destination port [50601], and cookie persistence requires a HTTP profile."

Does this sound correct? We have had issues in the past with creating "http" or "https" profiles for these ports since they are not traditional port 80 or port 443.

Thanks,

Brian
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Brian, the port numbers themselves do not matter, even though SAP's numbering scheme is unique. As to what your network admin is saying, this is correct, you can not make cookie persistence decisions on encrypted traffic without first terminating the SSL traffic on the BIG-IP itself. I'm assuming here that you are not terminating SSL on the BIG-IP but instead letting the SAP servers take care of SSL termination for you.

I would highly recommend moving the SSL certificates to the BIG-IP. The SAP deployment guide (http://www.f5.com/pdf/deployment-guides/f5-sap-dg.pdf) details how to configure the BIG-IP for this. Exporting the SSL certificates is done through the J2EE Visual Administrator tool in SAP. It's very straightforward and takes several minutes. You can then import the certificate to the BIG-IP which will allow your SSL traffic to also benefit from cookie persistence.

If you do this, you would have two options. You can either send the traffic to the NON-SSL SAP instance, in which case traffic would be encrypted all the way to the BIG-IP then unencrypted to the server or you can re-encrypt the traffic after the cookie decision is made and the traffic will be encrypted all the way to the SAP instance. In neither case will the user see anything usual or different. You will see big improvements in server CPU utilization by offloading SSL from the SAP servers and there should be a general improvement in response time as a result. However, the decision is one that you, your network admins and your security team need to make in concert.

I hope this helps, let us know if you have additional questions. The deployment guide does a fantastic job (I think, but let me know otherwise ;-) ) of describing how to configure SSL off-load in the BIG-IP. For exact instructions on exporting your SSL key and certificate from J2EE Visual Administrator, drop me an email.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Nojan,

We originally intended to offload the SSL onto the f5 (and continue using SSL to the app server), however, the network team was not able to configure the f5 for use with our internal Certificate Authority (Microsoft product). I beleive the issue may have been in the import of the certificate, and I think specifically in the naming in Step 6. of "Importing keys and certificates". I seem to recall that our CA has a long name with several "-" or "_" characters in it. I beleive they were trying to use that name and were coming out unsucessful. Since we were never able to get that working correctly, I had to give up the notion of SSL offloading. Again, I have no visibility into the f5 configuration myself, so there is not much I could do to try and help.

Thanks,

Brian
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
That's quite interesting. Do you have a public URL that you could share with me that I person direct my web browser to to see what you mean?

Hopefully the network team opened a case with our support to address this issue.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Nojan,

Unfortunately we have nothing public using the f5. Perhaps I can ask if they can create a case with support.

Thanks for all of your help,

Brian
0
Comments on this Answer
Comment made 30-Aug-2017 by Amy003 237

I am not sure whether my comment would be seen on such an old thread, but recently, I experienced similar issue. There's end-to-end ssl connectivity from user to SAP servers through F5. It's configured with source IP address as affinity method. The sessions were getting timed out prematurely when left idle. I increased the persistence timeout and it resolved the issue.

What I do not understand is are as following :- 1. Why increasing the time out settings for idle time out and configuring keep-alive did not maintain the session ? 2. Now when the user session is maintained for over an half-an-hour, I do not see it's connection logs on F5 tmsh using show sys connection command.

0