Clients getting RST when idle

Unanswered Question
May 7th, 2009
User Badges:


I have a pair of 11503's configured in one arm mode runnig version Everything works well, but some clients connect to Oracle databases and run queries that last for 5 - 6 hours. The session is OK for 3-4 hours then the CSS issues a RST and kills the connection. The same config (not in one arm mode) on a 11150 with version 6.10 works fine and doesn't issue a RST. Any ideas ?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Gilles Dufour Thu, 05/07/2009 - 07:15
User Badges:
  • Cisco Employee,

The CSS11500 is more aggressive with idle connections.

To increase the idle timeout, go under the content rule and enter the command 'flow-timeout-multiplier 100' this will give you a 30minutes idle timeout. (100 x 18 sec)


petermangnall Tue, 05/12/2009 - 00:26
User Badges:

I've tried adding this command but it hasn't worked. Any other ideas ?

Many thanks

Gilles Dufour Tue, 05/12/2009 - 02:21
User Badges:
  • Cisco Employee,


there is no other possible suggestion.

Either your flow is idle longer than 30 minutes, or you did not configure the command under the correct content rule.

Does the traffic match a content rule first ?

or is it simply routed through the CSS ?


petermangnall Tue, 05/12/2009 - 02:39
User Badges:

Here's the config for the content

content B****

redundant-index 202

add service EA***1

add service EA***2

advanced-balance sticky-srcip

sticky-inact-timeout 720

protocol tcp

vip address 10.xx.xx.xx

flow-timeout-multiplier 100


And here's the last packet from the CSS to the client.

Transmission Control Protocol, Src Port: 9015 (9015), Dst Port: aspen-services (1749), Seq: 55217, Len: 0

Source port: 9015 (9015)

Destination port: aspen-services (1749)

Sequence number: 55217 (relative sequence number)

Acknowledgment number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set

Header length: 20 bytes

Flags: 0x04 (RST)

This is after 3.5 hours of the session becoming idle and before the flow-timeout-multiplier 100 command went in.

the command does not appear to have made any difference.

Again many thanks


Gilles Dufour Tue, 05/12/2009 - 04:59
User Badges:
  • Cisco Employee,

Did the connection start before you added the command ?

The command only applies to new connections.

Also, if the connection gets ilde longer than the idle timeout, it is not immediately removed.

However it is marked as idle and will be removed later on when CSS estimate it is time to reclaim resources.

So, the reset could come when the connection is actually active.


petermangnall Tue, 05/12/2009 - 05:19
User Badges:

OK, I've now added flow-timeout-multiplier 2700 to give me a 12 hour timeout.

All sessions have been restarted.

I'll update tomorrow with the results.



Gilles Dufour Wed, 05/13/2009 - 07:16
User Badges:
  • Cisco Employee,

Last guess.... you have a group to do client nat ?

If so, the flow-timeout command must be configured there as well.

If that does not help, give us your full config and version.


Gilles Dufour Wed, 05/13/2009 - 07:49
User Badges:
  • Cisco Employee,

You may want to try a more recent version.

There is at least one ddts related to idle timeout in your version : CSCek48833.

If you know the port being used by your application, you can use the following command :

flow permanent port1

Here is a procedure to check the reason for the RST (just to confirm this is related to idle timeout)

1) go into debug mode (either llama, or ESC-X should get you there)

2) symbol-table load SPRITZ (using the showtech it appears that you only had a SCP in slot 1)

3) shell 1 1 FMShowReset

4) shell 1 1 WccShowReject

5) run the test that caused the RST condition

6) shell 1 1 FMShowReset

7) shell 1 1 WccShowReject

8) symbol-table unload SPRITZ

9) exit from debug mode


This Discussion