Messages in this thread | | | From | Jay Vosburgh <> | Subject | Re: [PATCH v6 0/4] Add support for IPV6 RLB to balance-alb mode | Date | Wed, 23 Mar 2022 09:38:45 -0700 |
| |
Jakub Kicinski <kuba@kernel.org> wrote:
>On Wed, 23 Mar 2022 08:35:03 -0600 David Ahern wrote: >> On 3/23/22 6:09 AM, Sun Shouxin wrote: >> > This patch is implementing IPV6 RLB for balance-alb mode. >> >> net-next is closed, so this set needs to be delayed until it re-opens. > >What I'm not sure of is why this gets reposted after Jiri nacked >it. A conclusion needs to be reached on whether we want this >functionality in the first place. Or someone needs to explain >to me what the conclusion is if I'm not reading the room right :)
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.
-J
--- -Jay Vosburgh, jay.vosburgh@canonical.com
| |