This series allows conntrack to insert a duplicate conntrack entry if the reply direction doesn't result in a clash with a different original connection. Background: kubernetes creates load-balancing rules for DNS using -m statistics, e.g.: -p udp --dport 53 -m statistics --mode random ... -j DNAT --to-destination x -p udp --dport 53 -m statistics --mode random ... -j DNAT --to-destination y When the resolver sends an A and AAAA request back-to-back from different threads on the same socket, this has a high chance of a connection tracking clash at insertion time. This in turn results in a drop of the clashing udp packet which then results in a 5 second DNS timeout. The clash cannot be resolved with the current logic because the two conntracks entries have different NAT transformations, the first one from s:highport to x.53, the second from s:highport to y.53. One solution is to change rules to use a consistent mapping, e.g. using -m cluster or nftables 'jhash' expression. This would cause the A and AAAA requests coming from same socket to match the same rule and thus share the same NAT information. This change adds a second clash resolution/drop avoidance step: A clashing entry will be added anyway provided the reply direction is unique. Because this results in duplicate conntrack entries for the original direction, this comes with strings attached: 1. The clashed conntrack entry will only be around for 3 seconds 2. The clashed entry will still fail to be inserted if hash chain grew too large. This entire series isn't nice but so far I did not find a better solution. Comments welcome.
