TCP, UDP, and ICMP timeout values...

Discussion in 'Networking Issues' started by SAPo57, Sep 27, 2006.

  1. SAPo57

    SAPo57 Network Guru Member

    In some routers by default the TCP, UDP, and ICMP timeout values are 300 seconds, while others have the TCP and UDP for 3600 seconds and the ICMP for 10-30 seconds.

    Some Cisco routers by default have the TCP timeout at 86,400 seconds, the UDP at 120 seconds, and the ICMP at 60 seconds.

    For my router I would like to set it up so that I can play online games without any connection problems, but also keep my LAN connection fast when downloading files on the internet.

    Someone told me to set my TCP timeout value to 24 hours, and UDP and ICMP to 1 hour.

    Any suggestions...
  2. slamcat

    slamcat Network Guru Member

    By default, most of the Linksys routers have their timeout values set to 5 days, and I believe the IP_conntrack (number of conncurrent connections available to the router) are set at either 1024 or 2048.

    I think setting the timeout value of 24 hours is a good tradeoff, but you also need to take into consideration how many connections your router may make in that 24 hour period. If it's more than the Ip_conntrack value, you're going to run into problems. And you can't just discriminately up the value to some outlandish number; the router's memory prevents that, because if it fills the table up to the point the router has a problem handling the load, it will freeze the router up solid.

    P2P people will proably want the conntrack set to something like 4096 with a 600 second timeout (10 minutes). Using firmware like DD-WRT, OpenWRT and Thibor gives you control over these. I use OpenWRT because I can modify damn near anything in the TCP control stack fairly easily (but if you're not comfortable with linux CLI you'd be better served using HyperWRT or DD-WRT for that).
  3. SAPo57

    SAPo57 Network Guru Member

    My router processes about 60-100 IP connections a day. Would the 24 hour timeout value for TCP be suitable still? Also, what about the one hour values for UDP and ICMP?
  4. slamcat

    slamcat Network Guru Member

    Keep in mind that internet traffic varies. Some connections are TCP, some are UDP, some are broadcast/ICMP/IGMP (ping) traffic.

    The best thing to do is to just hammer the crap out of the router, and, if you are using a third party firmware and have access to either SSH or the command line from the web interface, issue 'cat /proc/net/ip_conntrack | wc -l' That will give you the number of active connections in the conntrack table. If you issue that same command minus the pipe output, or, 'cat /proc/net/ip_conntrack', you'll see those entries, which look like the following:

    tcp      6 117 SYN_SENT src= dst= sport=32775 \
         dport=22 [UNREPLIED] src= dst= sport=22 \
         dport=32775 use=2
    Of course, the entry indicates a TCP connection, the next number is that connections protocol number (6), and the next is the TTL (time to live) in seconds.

    For a brief primer, the ip_conntrack bucket stores the connections for the length of time the TCP and UDP timeouts are set if they go unreplied. You'll see that status in the ip_conntrack table as [UNREPLIED]. When a connection is once again made (which means a full cycle connection; a send and receive on the entry in the bucket), that status will change to [ASSURED] and the TTL timer resets to the timeout values. If it remains unreplied, when the counter gets to 0, it flushes the connection from the table. If the TCP default of 5 days is left, you can see how quickly that would get full. Once it does get full, it usually will start throwing errors that you won't be able to see, and then it will lock up the router.

    It's easy to see how quickly this can get full. You need to test during a heavy instance and see how many are in the bucket, and adjust the ip_conntrack_max to something that both the memory in the router, and the number of concurrent connections you will use at a given time can handle. Sometimes you have to make a tradeoff; sometimes you have to reduce the timeouts.

    So to answer, I would say start with 3600 seconds on the TCP timeout, since most gaming uses UDP anyway, and set the UDP and ICMP to 120. Once you do that, start monitoring as I explain above and see how close to the ip_conntrack_max you are getting. I have mine set at 4096; the most I've ever seen in the conntrack at once (mind you, I don't game a whole lot) was about 80. I doubt you'd get it much over 200, and that's not going to hurt anything. Where the worry comes in is with the P2P programs that use a lot of connections.
  5. SAPo57

    SAPo57 Network Guru Member

    What protocols consume more bandwidth TCP or UDP?

    Also, I have only one user in my network that uses P2P programs at least 5 hours a day. Does only 5 hours really use a lot of ports? Will a 3600 second UDP timeout value still close those ports?

    Last question...Does watching music videos on a website such as use UDP connections as well?
  6. slamcat

    slamcat Network Guru Member

    TCP, by it's very design, will consume more just because the payload is larger. A good little primer is available on Wikipedia at

    UDP can be found at

    The reason that TCP is larger? TCP requires a state check from both the sending and receiving address. That's why TCP is considered a 'guaranteed' method of sending data. If an error is detected, the receiving machine can request a retry. UDP is not guaranteed, so if an error occurs, that packet is gone forever.

    Also, traffic that comes from website (such as tends to be TCP in nature, but if the streaming protocol calls for it, you can have some UDP connections. And P2P uses UDP connections. As I've said before, if you have access to the command line, watch the number of connections in the bucket compared to the set maximum. Even though you may have only 60 - 100 connections per day, that connection could easily spawn more.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice