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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Mar 2022 10:28:39 -0700
From:   Jakub Kicinski <>
To:     Jay Vosburgh <>
Cc:     David Ahern <>,
        Sun Shouxin <>,,,,,,,,,
Subject: Re: [PATCH v6 0/4] Add support for IPV6 RLB to balance-alb mode

On Wed, 23 Mar 2022 09:38:45 -0700 Jay Vosburgh wrote:
> 	The summary (from my perspective) is that the alb/rlb technology
> more or less predates LACP, and is a complicated method to implement
> load balancing across a set of local network peers.  The existing
> implementation for IPv4 uses per-peer tailored ARP messages to "assign"
> particular peers on the subnet to particular bonding interfaces.  I do
> encounter users employing the alb/rlb mode, but it is uncommon; LACP is
> by far the most common mode that I see, with active-backup a distant
> second.
> 	The only real advantage alb/rlb has over LACP is that the
> balance is done via traffic monitoring (i.e., assigning new peers to the
> least busy bond interface, with periodic rebalances) instead of a hash
> as with LACP.  In principle, some traffic patterns may end up with hash
> collisions on LACP, but will be more evenly balanced via the alb/rlb
> logic (but this hasn't been mentioned by the submitter that I recall).
> The alb/rlb logic also balances all traffic that will transit through a
> given router together (because it works via magic ARPs), so the scope of
> its utility is limited.
> 	As much as I'm all in favor of IPv6 being a first class citizen,
> I haven't seen a compelling use case or significant advantage over LACP
> stated for alb/rlb over IPv6 that justifies the complexity of the
> implementation that will need to be maintained going forward.

That's pretty clear, thanks!

Sun Shouxin please do not post new revisions of the patches
unless you can convince Jay your use case is strong enough,

Powered by blists - more mailing lists