dslreports logo

Moving the default NAT timers has benefits, such as the utilisation of a small timer, will clean the table and flush translations that are not active. It will free memory within the router for other purposes. I know that sounds great, but if for some reason one of your applications needs a large timeout to finish the session, the router if configured with a small timer will flush them and new sessions would need to be established. The cpu utilization will be lower in general, but there will be an increase in cpu processing (occurs in peaks) when the table gets flushed and new sessions are established. After that, it will resort again back to its low level, hence my use of the word peaks.

These timeouts will count individually for each NAT session, and after the session has been inactive for the time specified the router will flush it, if the session is active (some traffic is passing through it) the router won't start the timer. For some connections like FTP and telnet the TCP session is established and traffic start passing through, if the router sees a TCP-FIN packet it will flush the NAT connection, and if not, it will wait for the timeout, but for SMTP and HTTP, the session is established, but the applications won't send traffic unless you click on a link or download an email, so for that, the session is flushed by the router as soon as the timeout is reached. So the timeout of a session depends more on the application than the NAT timeout.

There are some applications like SQL, Citrix and other databases and thin clients that are really sensitive, and if the session is flushed and a process has not being finished the application would need to restart the process. Some others like MSN, HTTP and normal applications are not so sensitive and if the NAT session is flushed it will establish a new one and nothing will be noticed by the user.

At the other extreme, we have maximal timeouts and that brings with it a whole range of problems. A large, really large NAT timeout will impact the router's memory and result in latency in most of cases and in extreme scenarios the router can crash per a lack of memory. This is because all sessions that for any reason were not finished by a TCP-FIN packet, will stay in the router forever and ever and spend memory and CPU. Maybe one day the timer would be reached, but maybe not and the router crashes first.

So playing with NAT timouts is not condoned unless undertaken or supervised by someone experienced with NAT and its impact on various protocols. Cisco's default timeouts are adequate for most needs and do not need adjusting for any reason. It's only in extreme circumstances will the timeouts be evaluated and a test run with the protocols and sessions involved undertaken to determine its effect on the application(s) in question and its impact on router resources.


Derived from this thread:

»[HELP] Minimal NAT TCP/UDP timeouts?


Expand got feedback?

by Covenant See Profile edited by aryoba See Profile
last modified: 2006-06-26 18:56:27