CSS - Sessions get timed-out after 20 or 30 minutes

[astanislaus]

There are 3 proxy serevrs connected to CSS.

When the remote users set the CSS VIP address (that is 16.172.48.10 )as the proxy server in their IE browser settings the sessions disconnect (even when sessions are active and I am not talking of idle sessions) after 20 to 30 minutes. If, in the IE browser setting they set the real ip address (16.172.48.130 or 16.172.48.131 or 16.172.48.132) then it works fine pointing the problem to the CSS and not the proxy servers or any other part of the network. Diagram, SHOW TECH and logs attached. You will see some services going down and up but that is not the problem and we know why the service have gone down.

Customer says only when the user is using https that this problem happens, but not with http. For example they never have a problem when going to

http://www.yahoo.com

or

http://www.msn.com, but they do have a problem when for example going to:

https://connect2.vodafone.com.au/Citrix/MetaFrameXP/default/login.asp?ClientDetection=On

The session terminates after about 20 or 30 minutes.

[Gilles Dufour]

the idle flow timeout is 8 sec for http traffic.

Which means if you do not click on a link every 8 sec, the connection is considered idle and can be deleted at any time to server new connections.

Configure a 'flow-timeout-multiplier 50' under your content rule and see if it makes any difference.

Gilles.

[astanislaus]

Gilles,

The customer says that the session disconnects even when he is actively using it. So there is no question of idle timeout.

Regards

Alphonse

[Gilles Dufour]

Alphonse,

I just told you that the idle timeout is 8 seconds. Do you know a user that clicks a link every 8 sec continously ?????

let's says you click every 5 sec during 1 hour, then wait 9 sec one time, and then start clicking again every 5 sec. It is too late.

Once the CSS detects the connection idle, even if you start being active again, it will eventually decide to remove the connection.

So, follow my suggestion. I think after 10 years within Cisco and as a developper of the CSS I know what I'm saying.

G.

[astanislaus]

Sorry Gilles, I take your point. I will ask my customer to configure 'flow-timeout-multiplier 50' under the content rule and see what happens. It was just that when I suggested this to customer he says that the config of the CSS has always been the same for a long time and that the problem started only on 18th May 2007.

Some additional information given:

==================================

The customer says that his end users set the proxy as the VIP address of the CSS and when they do that they do not have any trouble of timing out or any problem at all when browsing http sites - exampel http://www.yahoo.com or http://www.msn.com

but the problem of the session getting disconnected occurs when browsing https sites.

Following questions asked to customer and his responses:

=============================================

Question: Are all users experiencing this dropout ?

Answer: There are a group of users from Australia accessing https://connect2.vodafone.com.au/Citrix/MetaFrameXP/default/login.asp?ClientDetection=On. If they are using via the Virtual URL (via CSS) and working on the website, the connection drops out after approximately after 20 mins. If they access the URL via proxy server directly, the connection remains healthy. This is happening to only the https website. Http URLs (like yahoo.com, msn.com) does not have any issues.

Question: How long has this been happening ?

Answer: Since May 18th 2007.

Question: Have any changes been made to the CSS config recently ?

Answer:There were no changes made at the CSS config

[pcarvill]

Hi guys,

I found this post interesting as I am seeing a similar issue with a client.

They have one notable https internet based application which is timing out approx. once a day. They have a content rule balancing between 2 proxy servers (proxy requests to port 80).

The content rule is set up for advanced balance source-ip and advanced sticky idle timeout of 24 hours.

The application is a real-time trading site (https). Therefore there are constant updates (perhaps not within 8 seconds, but for sure every minute).

My question is this; with balancing on source ip, do I still risk losing my flow after 8 seconds and switching to the second proxy server? Or will I lose the flow, but keep my sticky source entry so the next request still passes by the same proxy.

I believe while the client says the problem exists only for https, the problem is happening transparently for http. The problem we have is with the SSL termination on the proxies. If we switch proxies we have to recreate the https connection, thus our timeout.

Would configuring 'flow-timeout-multiplier 50' relieve this issue?

Many thanks in advance,

Paul

[Gilles Dufour]

Paul,

if you have sticky enable with a sticky timeout of 24 hours, you should only lose the idle flow and the next connection attempt should go back to the same server.

However, are you sure the connection can recover from the idle flow ???

A new flow is established only with a SYN.

And the flow is silently discarded - no RESET.

So, the client will eventually send data and it will generate a RESET from the CSS.

So, will the application accept the RESET, open a new connection and resend the data automatically, or will it prompt the user to do something ?

This is really dependent on your application.

I think the flow-timeout-mutliplier should always be increased to 50 unless your number of active connection is high [average of 80% of total number of possible connections]

Regards,

Gilles.

[pcarvill]

Thanks Gilles for your prompt response. Looks like I need to do some more homework. Thanks anyway for the explanation, much appreciated.

[pcarvill]

Gilles,

Just 2 last questions;

Do I need to suspend the rule to add this command?

If the flow is marked as idle, but stays in the table, will new traffic force the idle status to change or is it remaining idle regardless of current flows?

I hope I explained my question clearly.

Thanks again for your help.

Paul

[Gilles Dufour]

the status idle can't be changed. Even if new packets matching this flow comes in.

New connections will eventually force the CSS to delte the idle flow to reuse it for another connection.

Gilles.

[astanislaus]

Gilles,

We have modified the flow-timeout-multiplier as recommended. Still the customer says that when he sets his Browser's (Internet Explorer's) proxy to point to the VIP address, the session times out after exactly 20 minutes. But if he changes the Browser's proxy setting to point to anyone of the three server's real IP address he has no problem. Also the problem occurs only when accessing this one url which uses https:

https://connect2.vodafone.com.au/Citrix/MetaFrameXP/default/login.asp?ClientDetection=On

What is interesting is that the session disconnects exactly after 20 minutes even when the user is actively using the session. I said to customer may be the problem is elsewhere but not in the CSS. He says that "why then" it does not happen when using server's real IP address.

The problem happens not to one user but many many users - at least 15 users.

Modified config after adding "flow-timeout-multiplier 50" command:

=============================================

content Proxy_8080

advanced-balance sticky-srcip

add service snopxypro11-8080

add service snopxypro12-8080

protocol tcp

port 8080

vip address 16.172.48.10

add service snopxypro13-8080

flow-timeout-multiplier 50

active

[Gilles Dufour]

you will need a sniffer trace to verify exactly what is going on.

It can't be CSS timeout because we took care of if with the flow-timeout command.

Moreover we do not have a 20 min timer anywhere in the code.

Take a sniff when it works and when it doesn't and compare the 2.

Gilles.

[astanislaus]

Thanks Gilles. I have asked the customer for this from day 1 and I am still awaiting this.

[pcarvill]

Gilles,

Your suggestion fixed my problem.

Thanks for all your help.

Paul

[thumpercisco]

Hey G.

Calm down, you're the professional, remember.