Bonding several network cards: redundancy or speed
People bond cards for two different reasons, and the two are not the same mode. Most setups actually want redundancy, but configure for throughput, and the result is disappointment.
AtlasPVE ·
This entry answers
- what is a proxmox bond
- proxmox lacp setup
- proxmox combine two network cards
- proxmox active-backup bond
- proxmox lost connection after bond
The server has two network cards and you want to use both. Everyone is in the same place up to here. The split starts with the next question: why.
Two different goals
Redundancy: if a cable comes loose, a card dies or a switch port fails, nothing stops. The gain is continuity, not speed.
Total bandwidth: more traffic can be carried at the same time. The gain is capacity, and in return there is work to do on the switch side.
In most setups what is genuinely wanted is the first, but the configuration is done for the second. The result is usually two disappointments at once: the expected speed does not arrive, and the configuration becomes more fragile.
The dividing question: does the switch need to know
Some modes ask nothing of the other side and work with an ordinary switch. Other modes require a matching group to be defined on the switch. Choosing a mode from the second group without preparing the switch side is one of the most common ways to lose the machine, and it happens at the exact moment of applying.
The rule is simple: if you have no access to the switch, or cannot define anything there, choose the mode that asks nothing of the other side.
The most common misconception about speed
Bonding cards does not make a single transfer faster. A single connection stays on a single link. The gain appears when there are many connections at once. People bond two cards, test by copying one file, see the speed of one card, and call it broken. It is not broken, the measurement is wrong.
If your goal is to make one large transfer faster, a single faster card is the right answer, not bonding.
The least glamorous, most useful choice
The redundancy mode that asks nothing of the other side is the right answer for most servers. It gains no speed, but when a cable comes out nobody notices. It gets skipped for being boring, when it is exactly what most setups are looking for.
Untested means it does not exist
A bond is an assumption until it has been tested. Look at which link is actually carrying the traffic, then deliberately pull one cable at a moment you choose and see the traffic genuinely move to the other. Setups that skip this test find out on the day of a real failure that the bond never worked.
Do not get the order wrong
The bond is the physical layer, the bridge sits on top of it. Virtual machines attach to the bridge, not to the bond. Built the other way round, you get a structure that looks like it works and falls apart at the first failure.
What Atlas does
When you create a bond, Atlas shows the four modes with a description each and defaults to the mode that asks nothing of the other side, so the safest option is the starting point. If you pick a mode that requires a matching group on the switch, a warning appears, and the warning names the technology required and says plainly that the connection may drop. Even if you ignore the warning and continue, the network change is protected by a rollback countdown: if you do not confirm, the old configuration comes back on its own.
Sources
Proxmox's own documentation. In English, and it has the final word on this subject.