I have a CSS 11503 with a basic content rule for TCP 10000 going to a few backend servers. I was looking into the default timeout values for flows and when testing using telnet the flow didn't terminate as expected?
For example, i have no 'timeout multiplier' specified in the config and when i look at the output of 'show flow-timeout default' it tells me the default 16 seconds timeout is in effect for *. With that in mind, i telnet to the content rule vip on TCP 10000 and on the backend server using wireshark i can see the TCP threeway handshake. With no data passing i'd expect the CSS to terminate this flow after 16 seconds.. yet it takes exactly 128 seconds before wireshark shows the RST and the flow is terminated. 128 being 8 times the default 16 second flow timeout.
If i try to force the connection to close early by specifiying 'flow-timeout-multiplier 2' in the content rule, or even a multiplier of 40, it still waits 128 seconds to close the telnet connection.
Am i missing missing something? What does the CSS define an idle flow to be?
CSS will not send a reset when the flow times out.
16 seconds of idle if not muliplied means that when the flow is idle for 16 seconds it becomes eligible for garbage collection and the flow is moved to a sppof table. Internally the flow control block is reclaimed, however nothing is reset , if the client or server then sends data the data will go through as long as the spoof table is not full (32k). If the spoof table fills and it is the oldest entry when the client sends data he will get a reset back.
You can achive an idle timeout where th eload balancer sends a reset if you are using a cisco ace module or appliance , however CSS has no idle timeout that sends a reset. If you want to reset an idle connection you need to do that at the server.