Lost SQL Server sessions

hi, To solve this problem, you should increase session_timeout for SQL connections. Try these: config system session_ttl config port edit 1433 set timeout 3600 next end end where, 1433 is the sql port value and 3600 is the session time in second. umit.

Deon, I don' t have a solution for this issue, but I think I know what is going on in that Fortigate 200 box of yours. I am currently trying to convince Fortinet R&D about a bug related to the way Fortigate handles TCP half close connections (FIN_WAIT2 state). Your description of this issue looks rather familiar to what I am experiencing with raw LPR and RSH connections: Most connections work fine but it occurs at random that some connections seem to be time-out, although the session_ttl was set to a couple of hours and filtering is obviously not causing the problem. Below my findings, hope it makes any sense to you. I am convinced that Fortinet has implemented the 2*MSL WAIT for TCP connection termination during the half close (FIN_WAIT2 state), instead of after the full close (TIME_WAIT2 state) as defined in RFC793. What this means is that a time-out is set during the the half close and if the remote party does not fully close the connection within the time-out set by the Fortigate, the session expires. According to the TCP specification no time-out should be used during the half close state, but the unwanted implicit " indefinite" wait has caused many implementations to use a time-out value here anyway. It seems to me that the Fortigate firewall launches the 2*MSL wait during the half close. I have setup some tests and I have seen that my Fortigate(s) lower the active session_ttl when the connection state transitions to the half close state. On MR6 this was 120 seconds followed by an additional wait of 10 seconds. With MR7 and higher, this time-out value was lowered to 30 seconds, without the additional wait of 10 seconds. The latter is a very common 2*MSL implementation nowadays (RFC1323), however, the issue here is obviously that Fortinet either implemented a very low time-out during half close (FIN_WAIT2 state), which looks very much like a 2*MSL implementation to me or it launched the 2*MSL wait too early! My advise for now is to check what SQL transactions take longer than 30 seconds to complete and tune them, or downgrade to MR6 so your SQL transaction have more time to finish. Brgrds, Frank

Frank, Thanks very much for the response. What you describe is a bit outside my level of expertise, but it makes perfect sense and fits my situation. I' m escalating this to Fortinet. If I get anywhere, I' ll let you know. Cheers Deon

Deon, Check the tcp-halfclose-timer in MR10. Good luck with your tweaking! Rgrds, Frank