Hello Andreas, Am 26.07.2016 um 13:42 schrieb Andreas Herz: > we have a system with a huge amount of TCP ESTABLISHED connections but > all [UNREPLIED] that have the 5 days timeout from > nf_conntrack_tcp_timeout_established. Increasing conntrack_max is just > delaying the issue. > > I could run a script to get rid of them via cronjob but I found this in > the neftilter documentation: > >> The answer is easy: UNREPLIED entries are temporary entries, i.e. as >> soon as we run out of connection tracking entries (we reach >> /proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries. >> In other words: instead of having empty conntrack entries, we'd rather >> keep some maybe useful information in them until we really need them. > > (http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html) > > But I'm getting: > >> kernel: nf_conntrack: table full, dropping packet. > > Should this "garbage collection" still work or would it be a good idea > to implement a dedicated and much smaller counter for those connections? I'm skirting your issue here, but have you tried: echo "0" > /proc/sys/net/netfilter/nf_conntrack_tcp_loose We've had a similar problem like you, where a partner's firewall would not ack FIN packets but rather send a TCP RST in reply, which would then create a phantom "ESTABLISHED/UNREPLIED" connection in conntrack. In our case we did not run into problems with conntrack overflowing, but rather we saw our gateway sending RST packets for next SYN requests with the same source ip:port tuple. Setting this configuration key to zero made that problem go away. HTH, Thomas -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
