netdev - 答复: [vger.kernel.org代发]Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b9e0245f58ca44ed80b07a58cd0399be@inspur.com>
Date:   Mon, 15 Jun 2020 06:56:33 +0000
From:   Yi Yang (杨燚)-云服务集团 
        <yangyi01@...pur.com>
To:     "dsahern@...il.com" <dsahern@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>
Subject: 答复: [vger.kernel.org代发]Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop?

Hi David

My next hops are final real servers but not load balancers, say we sets maximum number of servers to 64, but next hop entry is added or removed dynamically, we are unlikely to know them beforehand. I can't understand how user space can attain consistent distribution without in-kernel consistent hashing, can you show how ip route cmds can attain this?

I find routing cache can help fix this issue, if a flow has been routed to a real server, then its route has been cached, so packets in this flow should hit routing cache by fib_lookup, so this can make sure it can be always routed to right server, as far as the result is concerned, it is equivalent to consistent hashing. 

Can you help confirm if my understanding is right? It will be a big problem if no. It will be great if you can show me user space can attain this without kernel help.

-----邮件原件-----
发件人: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] 代表 David Ahern
发送时间: 2020年6月12日 12:37
收件人: Yi Yang (杨燚)-云服务集团 <yangyi01@...pur.com>; netdev@...r.kernel.org
抄送: nikolay@...ulusnetworks.com
主题: [vger.kernel.org代发]Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop?

On 6/11/20 6:32 PM, Yi Yang (杨燚)-云服务集团 wrote:
> David, thank you so much for confirming it can't, I did read your cumulus document before, resilient hashing is ok for next hop remove, but it still has the same issue there if add new next hop. I know most of kernel code in Cumulus Linux has been in upstream kernel, I'm wondering why you didn't push resilient hashing to upstream kernel.
> 
> I think consistent hashing is must-have for a commercial load balancing solution, otherwise it is basically nonsense , do you Cumulus Linux have consistent hashing solution?
> 
> Is "- replacing nexthop entries as LB's come and go" ithe stuff https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#resilient-hashing is showing? It can't ensure the flow is distributed to the right backend server if a new next hop is added.

I do not believe it is a problem to be solved in the kernel.

If you follow the *intent* of the Cumulus document: what is the maximum number of load balancers you expect to have? 16? 32? 64? Define an ECMP route with that number of nexthops and fill in the weighting that meets your needs. When an LB is added or removed, you decide what the new set of paths is that maintains N-total paths with the distribution that meets your needs.

I just sent patches for active-backup nexthops that allows an automatic fallback when one is removed to address the redistribution problem, but it still requires userspace to decide what the active-backup pairs are as well as the maximum number of paths.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (3600 bytes)