The default conntrack timeout for UDP streams is 180 seconds, which is
within that range. The protocols that need that are streams rather than
transactional protocols like DNS. (Although the other suggestion to
remove DNS immediately on reply would even cause trouble for DNS,
because some clients send multiple DNS queries at the same time using
the same ports, e.g. IPv6 (AAAA) and IPv4 (A) queries, and immediate
removal would cause the other replies to be lost. One second timeouts
could do the same.)
The main problem with very short global UDP stream timeouts is for IPsec
tunnel mode, OpenVPN, or anything else that encapsulates traffic in UDP
or otherwise needs the UDP entry to continue to exist indefinitely. If
the app's keepalive interval is shorter than the timeout then packets
that arrive between the timeout and the keepalive packet go to the bit
bucket.
Some applications will try to detect that and then shorten the keepalive
interval (but not all, and generally only after several packets are lost
with user-visible consequences). And even then the result is more
deadweight keepalive packets consuming network resources and requiring
power-expensive radio wakeups on battery-powered user devices.
On 09/05/2016 04:40 AM, André Paulsberg-Csibi (IBM Consultant) wrote:
I have yet to see any implementation of any FW in 2014 - 2016 that has UDP timeouts in the 2-5 minutes range , as described in RFC 4787 .
IF I remember UDP implementations from a lot of todays firewalls is typically set default timeout to about 30-40 seconds ,
and despite RFC4787 I would rather recommend having lower timeouts for UDP and higher ones for just those
protocols that require this than to have 2-5 minutes for UDP which in most cases never last more then 2-4 seconds .
That seems like an unreasonable reverse logic and use of resources , looking at today vs 10-20 years ago's most common UDP traffic patterns .
But yes , I agree on increasing connection table in either case as this was clearly low for such current level of sessions
and find the root cause for the high amounts of sessions and fix that if possible ...
Best regards
André Paulsberg-Csibi
Senior Network Engineer
Fault Handling
IBM Services AS
andre.paulsberg-csibi@xxxxxxxx
M +47 9070 5988
-----Original Message-----
From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of zrm
Sent: 2. september 2016 16:48
To: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx>; John Ratliff <jratliff@xxxxxxxxxxxxxx>; netfilter@xxxxxxxxxxxxxxx
Subject: Re: nf_conntrack_max
On 09/02/2016 02:27 AM, André Paulsberg-Csibi (IBM Consultant) wrote:
In the meantime there is no real issues increasing you the connection table while you figure that out ,
and you can also GLOBALY fix the UDP timeouts if you so desire as most likely this can be lowered significantly from
the defaults , here you can see one example from a smaller FW then yours ( but still applicable ) :
zotac:~ # grep netfilter /etc/sysctl.conf
net.netfilter.nf_conntrack_max = 10000
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 40
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 40
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 40
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 40
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 40
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_udp_timeout = 10
Global timeouts that short can cause other trouble though. See RFC4787
Section 4.3 and RFC5382 Section 5. Outside of reducing the timeout only
for DNS, the best choice is probably just increasing the maximum number
of conntrack entries (and buying more memory if necessary).
--
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
--
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
