Connection Tracking,

Greetings, colleagues, I want to optimize my connection tracking to lower CPU and active connections without reason. I have a ccr2116 running with fasttrack, 5Gbps of traffic and 217,000 connections at peak times.
What do you think about this modification?



generic-timeout=3m \ # Reduce from 10 minutes to 3 minutes
tcp-established-timeout=30m \ # Reduce from 1 day to 30 minutes
tcp-close-timeout=5m \ # Reduce from 10 minutes to 5 minutes
tcp-time-wait-timeout=5m \ # Reduce from 10 minutes to 5 minutes
tcp-syn-sent-timeout=1m \ # Reduce from 5 minutes to 1 minute
tcp-syn-received-timeout=1m \ # Reduce from 5 minutes to 1 minute
tcp-fin-wait-timeout=5m \ # Keep at 5 minutes
tcp-last-ack-timeout=5m \ # Keep at 5 minutes
tcp-close-timeout=5m \ # Keep at 5 minutes
tcp-max-retransmit-timeout=5m \ # Keep at 5 minutes
tcp-unacked-timeout=5m \ # Keep at 5 minutes
udp-timeout=15s \ # Keep low for ephemeral traffic
udp-stream-timeout=3m \ # Keep at 3 minutes for UDP flows
icmp-timeout=10s \ # Keep at 10 seconds

I’m not qualified to say anything about the other timeouts, but let me share a piece of advice regarding “tcp-established-timeout”.

I suggest setting it to 7440 seconds (2 hours 4 minutes) at a minimum due to RFC 5382 (NAT Behavioral Requirements for TCP).

https://datatracker.ietf.org/doc/html/rfc5382#section-5

Quoting from it:


[…] Some end-hosts can be configured to send keep-alive packets on such idle connections; by default, such keep-alive packets are sent every 2 hours if enabled [RFC1122]. […]



[…] In such cases, the value of the “established connection idle-timeout” MUST NOT be less than 2 hours 4 minutes. […]