09-09-2004 11:09 PM
hi,
First of all I should say I'm not a CSS expert, so here goes ...
On the css we have a content rule that listens to ip 1.1.1.1 on port 443 (NOT SSL, I use this port so customers don't have to modify their firewalls to be able to connect to the application)
We have a service that connect to ip 2.2.2.2 on port 3010 (PAT)
We use NAT by Group -> service -> adress 3.3.3.3
A client connects to 1.1.1.1 on port 443
The CSS does NAT & PAT and forwards to 2.2.2.2 port 3010 with source 3.3.3.3
The application on server 2.2.2.2 does a tcp keep-alive check every five minutes.
Most of the time this works fine (99%). The other 1% however we get a connection time-out on the application server
and a "connection lost" on the client side.
When i do a network trace i can see that the CSS receives three tcp keep-alive requests from the application server but doesn't forward them to the client. The application servers gives a time-out since it doesn't get any respond on its tcp keep-alive requests. The next packet that is sent by the client is received by the CSS, yet it doesn't forward this to the backend application server. Instead it sends a RST to the client.
This makes me conclude that for some weird reason the CSS terminates the active session and refuses the tcp keep-alive requests from the application server and data packets from the client. I don't understand why, since the previous (which are forwarded to the client) keep-alive request packets are identical and within the same time frames.
Has anybody encountered anything like this ?
Kind regards,
Ronny
Solved! Go to Solution.
09-09-2004 11:44 PM
this is no weird reason [when you know the way the CSS works].
The CSS does most of the switching in hardware but has limited resources.
So it has an agressive way to delete idle flow.
The idle timeout is 16 seconds for TCP.
So, with a keepalive of 5 minutes you are way above the idle timeout.
However, it's not because a flow is idle that it is automatically deletec.
There is a process called garbage collection that decides if it is needed to kill a flow or not.
It is dependent on how many connections per second you get on this box.
There are solutions to this.
You can increase the idle timeout on the CSS.
For a CSS 110xx or 111xx you can use the command
'flow port1 443 timeout 600' to set the timeout to 10minutes.
For a CSS115xx, you can use the rule command 'flow-timeout-multiplier 20' [20 x 16 sec = 320 > 5 min].
Regards,
Gilles.
09-09-2004 11:44 PM
this is no weird reason [when you know the way the CSS works].
The CSS does most of the switching in hardware but has limited resources.
So it has an agressive way to delete idle flow.
The idle timeout is 16 seconds for TCP.
So, with a keepalive of 5 minutes you are way above the idle timeout.
However, it's not because a flow is idle that it is automatically deletec.
There is a process called garbage collection that decides if it is needed to kill a flow or not.
It is dependent on how many connections per second you get on this box.
There are solutions to this.
You can increase the idle timeout on the CSS.
For a CSS 110xx or 111xx you can use the command
'flow port1 443 timeout 600' to set the timeout to 10minutes.
For a CSS115xx, you can use the rule command 'flow-timeout-multiplier 20' [20 x 16 sec = 320 > 5 min].
Regards,
Gilles.
09-09-2004 11:46 PM
Forgot to say :
CSS 11501 with SSL accelerator
Version: sg0720104 (7.20 Build 104)
Flash (Locked): 7.20 Build 3
Flash (Operational): 7.20 Build 206
Type: PRIMARY
Licensed Cmd Set(s): Standard Feature Set
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide