Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Clients getting RST when idle

Hello

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 ?

Thanks

10 REPLIES
Cisco Employee

Re: Clients getting RST when idle

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)

G.

New Member

Re: Clients getting RST when idle

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

Many thanks

Cisco Employee

Re: Clients getting RST when idle

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.

New Member

Re: Clients getting RST when idle

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

Cisco Employee

Re: Clients getting RST when idle

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.

New Member

Re: Clients getting RST when idle

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

New Member

Re: Clients getting RST when idle

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

Cisco Employee

Re: Clients getting RST when idle

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.

New Member

Re: Clients getting RST when idle

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

Cisco Employee

Re: Clients getting RST when idle

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

1420
Views
0
Helpful
10
Replies
CreatePlease to create content