On Thu, May 1, 2008 at 8:37 AM, Tom Strader <[EMAIL PROTECTED]> wrote: > We even started a ping to an IP on the same subnet. Ping never blinked but > at 4 minutes the Telnet session dies. [...] > There is a timeout value for NAT translations and packet streams..
ICMP is stateless; each Echo Request is independent from all the others. So if you're running "ping -t", the NAT doesn't see that as a "connection", it sees it as a bunch of individual Echo Request messages, over and over again. So that will be a different scenario vs Telnet. Telnet uses TCP, which is statefull -- there's a connection setup, which all following datagrams will be associated with. Are these Telnet sessions sitting idle (no keystrokes or screen updates)? I'm guessing there has been no activity, so no datagrams are being sent as part of that TCP connection. The NAT eventually decides the connection has died without being closed properly, and drops the state it uses to keep track of that TCP connection. If that's the problem, look for a feature in your Telnet software for something called "keep alive". That will cause the system to send an occasional datagram, even though there's been no real activity. That should keep the NAT happy. If the NAT is just putting a hard limit of 4 minutes on even active connections, then the only solution is to adjust that limit. Most good NAT implementations let you adjust the limits independently. It's generally fine to have a very long (days, weeks, even months) limit for active sessions. As long as there's data flowing, we don't care how long that connection is being used for. But be cautious about setting the "idle timeout" too long. The NAT may accumulate a lot of state about dead connections, leading to resource exhaustion in the NAT. How long "too long" is depends on the capabilities of your NAT, the total load, and how often connections die without a proper TCP close. -- Ben ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
