Not without using multiple flows.
With the specific exceptions of the round-robin and broadcast modes for Linux's bonding driver, neither of which will actually work correctly for your stated scenario (more on that below), all the bonding modes assign each connection/flow to a specific bound device.
This means that for single-flow use cases, they cannot provide load balancing, only fail-over.
This is done for a couple of reasons:
- It significantly reduces the overhead associated with running over a bonded interface. If a decision had to be made for each individual packet, then that would eat into the peak performance of the bonded interface. By only making the decision per-flow, that overhead is only present for the first packet of a flow.
- A lot of higher-level network protocols are reliant on in-order delivery of packets to function correctly. Some layer 4 protocols can guarantee this even if lower layers do not, but there are still a depressing number of applications that do not use such protocols and do not do their own sequencing.
- A lot of things at layer 4 or lower actually need in-order delivery of packets to function efficiently. Consistently out of order delivery causes all kinds problems with TCP for example, and severely limits effective bandwidth.
- Most smart switches and routers operate in terms of flows as well, which means that they may run into issues when dealing with packet scheduling that does not operate in terms of flows.
Because they operate in terms of flows though, you end up in a situation where any one flow is not guaranteed any more bandwidth than the lowest bandwidth bound device can provide. You can work around this by using multiple flows.
Assuming your switch plays nice with it, you probably want balance-alb mode, as it will give you the best overall link utilization spread across the links. However, some network hardware does not like how that mode handles receive load balancing, in which case you almost certainly instead want 802.3ad mode (if your switch supports it, and all the bound interfaces are connected to the same switch) or balance-xor (does the same thing, but the switch has to infer what’s going on, so does not work as well in all cases).
Why won’t balance-rr or broadcast work?
These two bonding modes are special.
broadcast mode largely exists just to provide a bonding mode that can handle the loss of a bound interface without any disruption whatsoever (active-backup mode, which provides similar fault-tolerance, will show a small latency spike if the active bound interface goes down because it has to reroute traffic and force updates of external ARP caches). It’s realistically only usable on layer 2 point-to-point links between systems that are both using the bonding driver (possibly even the same mode), and gives you no performance benefits.
balance-rr mode is instead designed to have minimal overhead, irrespective of whatever other constraints exist, and it actually does traanslate to evenly balancing the load across all bound interfaces. The problem is that if there is more than one hop below layer 3, this mode cannot provide packet ordering guarantees, which in turn causes all kinds of issues with congestion control algorithms, functionally capping effective bandwidth. It is also, in practice, only usable on layer 2 point-to-point links between systems that are both using the bonding driver.
