Timeout settings

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?

 

 

 

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

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.

Nojan,

 

 

I setup a similar scenario utilizing firbug with firecookie enabled.

 

 

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

 

 

Browser2: http://.company.com:/... - 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?

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).

 

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

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://.company.com, I automatically get redirected to https://.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

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.

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

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.