Bonding joins two or more ports into one interface. You do it for one of two reasons: more throughput between two devices, or carrying on when a cable or a port fails. Which of the two you get depends on the mode you pick, and in practice often on the traffic as well.
Where it sits
In advanced, under Bridge and ports, in the Bonding / LACP group. The wizard does not ask about it; this is something you add deliberately.
You add a bond and fill in four things: a name (bond1 by default), a mode, the ports that go in it, and whether the bond should join the bridge.
The modes
- 802.3ad (LACP), the default. The two ends talk to each other and agree which links take part. This is the mode you want when the device at the other end supports LACP, because only then do both ends know when a link is down. The script adds
transmit-hash-policy=layer-2-and-3andlacp-rate=1sec. - balance-xor: spreads traffic over the links with the same hash, but without talking to the other end. Usable against a switch that does static link aggregation and not LACP. It also gets
transmit-hash-policy=layer-2-and-3. - active-backup: one link carries everything, the other waits. No extra throughput, but the simplest form of redundancy, and the only one that works against a device that knows nothing about bonding at all.
- balance-rr: packets alternate across the links. It does give a single connection more speed, but it delivers packets out of order, which TCP handles badly. Only sensible in a controlled setup.
- broadcast: everything across every link at once. No throughput, maximum redundancy, and never what you meant unless you really meant it.
- balance-tlb and balance-alb: spread traffic without the other end doing anything, tlb outgoing only and alb incoming as well. They lean on ARP tricks and are more sensitive to odd cases than LACP.
Every mode gets link-monitoring=mii: the bond checks whether the port has physical link. A cable that is plugged in but passes nothing goes unnoticed; for that you need LACP, or Netwatch.
Which ports
Pick the ports in the Ports field. They are removed from the bridge port list automatically, because a port cannot be a bond member and a bridge member at once. The emergency port may not go in: that is an error, and rightly so, because your emergency access would then depend on exactly the layer an emergency port exists to bypass.
Use ports that resemble each other. Two ports of the same speed on the same chip behave predictably; a copper port and an SFP with different properties less so.
In the bridge or not
The in the bridge switch is on. The bond then joins the bridge and behaves like an ordinary LAN port. Switch it off when the bond needs an address of its own, for example for a direct link to a server or a second router.
Careful with VLANs: the port assignment in the VLANs section only knows physical ports, not bonds. A bond in the bridge is therefore treated as an access port on the first VLAN. If your bond has to be a trunk, add the /interface bridge port and /interface bridge vlan lines for it by hand after pasting.
When it helps and when it does not
It helps when many connections share the link at once: a trunk between two switches, an uplink to a virtualisation host, a NAS ten people work on. Traffic is spread by a hash over MAC and IP addresses, so different pairs land on different links.
It does not help a single transfer. Copy one large file from one workstation to one NAS and that traffic is a single flow, so a single link, and you get the speed of one cable. Two times 1 Gbit/s is not 2 Gbit/s for one copy. If that is what you need, one faster port is the real answer.
It also does not help against a broken switch or a power cut: both cables go to the same device. For that kind of failure, look at high availability.
What the script makes of it
You get a line like /interface bonding add name=bond1 mode=802.3ad slaves=ether7,ether8 transmit-hash-policy=layer-2-and-3 link-monitoring=mii lacp-rate=1sec, and, when the bond joins the bridge, a matching /interface bridge port add. Check afterwards with /interface bonding monitor bond1 that every link is active.
What goes wrong
- The other end is not configured. This is the most common mistake. Bonding only works when both ends know about it; the configurator cannot see the device at the other end and cannot check this for you. Set up the other end first, or use active-backup if that end can do nothing.
- A loop while you build it. As long as one end sees two separate ports and the other sees a bond, you have two parallel paths. Spanning tree usually catches it, but only plug the second cable in once both ends are ready.
- The speed does not double. Look at what crosses the link. One flow stays on one link.
Read on: Bridge and ports for the bridge around it, VLANs for tagged traffic, and High availability for redundancy at device level.