Re: nfqueue hashing on TCP/UDP port

[Florian Westphal <fw@strlen.de>]

Jake Owen <jake.owen@superloop.com> wrote:
> Hello!
> 
> tl;dr Is there a technical reason why nfqueue balance as implemented
> does not use TCP/UDP ports as well as source/destination IP addresses?

To keep host-to-host comunication on the same queue, for ftp, sip and
other highlevel protocols where a logical connection consists of
multiple tcp/udp flows.

> We've been having trouble with the queue hashing algorithm used by
> iptable's `--queue-balance` for traffic generated on-box (e.g. by a
> squid proxy) where a large percentage of traffic would be TCP, source
> IP of the proxy, and one google/microsoft/apple destination IP. This
> is made worse if the random seed causes two or more of these high
> traffic services to hash to the same queue. We are working on
> preserving the original client IP as the source IP to provide
> sufficient randomness to balance accurately, but in the meantime have
> wondered if balancing by port was not implemented because it was
> deemed unnecessary, or because of some technical reason which escapes
> me.

The latter.  I will add arbitrary hash keying to nft, its currently
only missing from the frontend.

Will put you in CC when its done.

> I'm willing to propose a solution for
> the latest 5.x kernel if other people think that this is a valid
> solution/use case.

With nft this will soon be possible:

queue num jhash ip daddr . tcp sport . tcp dport mod 16

... which will queue to 0-15.

I don't think we need code changes to the xtables backend.