On 26/07/16 at 14:29, Thomas Bätzler wrote: > 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. So far this helps yes, also got the hint from Florian Westphal that with newer kernels this issue should be better with that commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6547a221871 Thanks for the hint! -- Andreas Herz -- 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
