I have a pair of 11503's configured in one arm mode runnig version 08.10.1.06. 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 ?
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)
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 ?
Here's the config for the content
add service EA***1
add service EA***2
vip address 10.xx.xx.xx
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
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.
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.
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.
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