cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1011
Views
0
Helpful
4
Replies

flow-timeout-multiplier

cliff.bowles
Level 1
Level 1

When you configure this on a content rule and the idle timer expires, the CSS reclaims the flow. I am wondering if anyone knows whether the CSS issues a TCP RST in both directions (server and client) or if it just drops the session info from its table. The idle timer on a Microsoft NNTP server is 10 minutes (I believe). People using Outlook Express sometimes report a message (your TCP session was unexpectedly reset by the server). I'm wondering if that is because the CSS is reclaiming the flow without issuing a RST? My next step is to bump the timers up higher than the server so that hopefully the server can issue a graceful shutdown of the session.

CWB.

4 Replies 4

seilsz
Level 4
Level 4

Hi Cliff,

The CSS will not generate a tcp rst when the flow is reclaimed. However, if the flow is subsequently removed from the internal cache, the CSS will generate a rst in response to traffic received on that connection.

~Zach

What determines when this flow is removed from internal cache, and is this a controllable setting?

When you are on an OE client and you connect to a server, if you take a packet capture, you will see a RST come from the server at 10 minutes. The OE client knows not to try and continue on the current socket, so even after a period of idle the session is renegotiated on the back end and the user sees no messages.

With the CSS, we had the flow-timeout-multiplier set to 4 minutes and were under the impression that after 4 minutes, the virtual-incativity-timeout timer begins in the ssl-server-list. That is set to 900 (15 minutes). But we are still seeing from the client side that the RST packet never arrives. therfore, after a period of idle, the user attempts to upload a mail and the OE tries to use the same socket, it fails, an error is sent to the user and then it renegotiates.

I was hoping that by bumping these settings up, we could ensure that the server-issued RST will make it to the client. Perhaps we should modify the retention settings on the internal cache?

Thanks for the help, by the way.

Flows are removed from the internal cache in fifo order, and this is not configurable. This means that the amount of time a flow spends in the internal cache is based on the flow rate through the CSS.

I would recommend that you set the virtual inactivity-timeout and the flow-timeout-multiplier to the same values.

~Zach

If you want your OE client to see the RST sent by the server after its 10 minute idle timer expires, you need the CSS to keep the flow for at least 10 minutes. Otherwise the CSS drops the flow before the server sends the RST.

Review Cisco Networking for a $25 gift card