CSS Flow Timeouts

Unanswered Question
Apr 18th, 2009
User Badges:


I have two separate Unix servers behind a CSS running v8.1. They are accessed via Content/Service rules from client workstations with a one to one mapping between the Content Rules/Services.

When we SSH to one server the SSH connection never times out. On the other server it seems to time out after about an hour.

I've shown I can resolve the ssh timeout on the "broken" server by setting a flow timeout multiplier of 0 for the appropriate content rule. The ssh connection is no longer timed out.

On the first server where ssh connections weren't timed out - I found that the tcp_keepidle and tcp_keep_intvl were set to much lower values (5mins for tcp_keepidle and 5 sec for tcp_keepintvl).

On the second server where the SSH connections timed out, the tcp_keepidle and tcp_keepintvl were set to much larger values of 2 hours and 75 sec respectively.

Armed with the information that the default tcp timeout for the CSS is 16 seconds - I'm struggling to explain how SSH connections to the first server don't timeout in the same way. Since the tcp_keepidle time on the server (which I believe to be the time between the connection becoming idle and the point at which the server begins to send keep-alives) is greater than the default CSS flow timeout.

Is there an internal "minimum flow lifetime" that the CSS respects?

Any other ideas?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Gilles Dufour Sun, 04/19/2009 - 07:58
User Badges:
  • Cisco Employee,

If the connection did not timeout on the first rule, it means there is traffic every 16seconds or less.

No other explanation.

Best way to be sure is to take a sniffer trace.

Also, a connection that is marked idle, is not removed immediately by the CSS.

We keep it in the system as long as possible. The buffer is just put in the re-use pool at the end. This is a LIFO queue. So, it takes a while for the buffer to get reused.

The time it takes is dependent on traffic activity.

When we eventually reuse the buffer, the connection is finally killed, so the new one can use the buffer.



This Discussion