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

Many thanks

Many,

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 ?

G.

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

active

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

Peter

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.

G.

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.

Thanks

Peter

No difference, all sessions timed out after 3 - 3.5 hours.

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.

G.

OK, attached is the full config, it's completely sanitised i'm afraid.

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