netdev - [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 for Android: free password hash cracker in your pocket

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

Message-ID: <6f0bf0c31d634134a0bf4ed4dbf17f9c@inspur.com>
Date:   Thu, 11 Jun 2020 14:56:03 +0000
From:   Yi Yang (杨燚)-云服务集团 
        <yangyi01@...pur.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        Yi Yang (杨燚)-云服务集团 
        <yangyi01@...pur.com>
Subject: [PATCH] can current ECMP implementation support consistent hashing
 for next hop?

Hi, folks

We need to use Linux ECMP to do active-active load balancer, but consistent hash is necessary because load balance node may be added or removed dynamically, so number of hash bucket is changeable, but we have to distribute flow to load balance node which is handling this flow and has current session state, I’m not sure if current Linux has implemented the algorithm in  https://tools.ietf.org/html/rfc2992, anybody can confirm yes or no?

I checked source code in https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/ipv4/fib_semantics.c#n2176, every next hop in fib has a upper_bound, fib_select_multipath just checks if hash value is greater than upper_bound of next hop and decide if it is selected next hop, so I don't think current linux has implemented consistent hash, please correct me if I'm wrong.

Thank you all so much in advance and sincerely appreciate your help.

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