cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
812
Views
0
Helpful
2
Replies

CSS closes tcp session

dbeynaerts
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

Gilles Dufour
Cisco Employee
Cisco Employee

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.

View solution in original post

2 Replies 2

Gilles Dufour
Cisco Employee
Cisco Employee

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.

dbeynaerts
Level 1
Level 1

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

Review Cisco Networking for a $25 gift card