There is one cable between two switches and it is full. The reflex is a second cable next to it with LACP on top. Sometimes that is the right answer. More often it solves a problem that turns out to be shaped differently than it looked.
What a bond does and does not do
A bond spreads traffic over its members using a hash. For 802.3ad and balance-xor the tool sets transmit-hash-policy=layer-2-and-3: the choice is made from the MAC and IP addresses of sender and receiver. That means:
- One conversation stays on one cable. A file copy from one server to another has one source and one destination, so one hash, so one link. Two times 1 Gbit/s does not become 2 Gbit/s there, it stays 1 Gbit/s.
- Many conversations do spread. Fifty workstations to fifty destinations fill both cables reasonably evenly.
- It does not spread cleverly. The hash knows nothing about load. If the two heaviest flows happen to land on the same link, that is where they stay.
- Bonding happens in the CPU, not in the switch chip. On a device that normally switches at wire speed, a bond therefore costs throughput rather than adding it.
The fairer question is often: can there be one faster cable? Replacing two copper ports with a single 10 Gbit/s SFP+ is simpler, faster and less to explain. See Several buildings with fibre.
When it does help
- Redundancy. Then do not pick 802.3ad but active-backup: one cable active, one waiting. Simple, predictable, and the hash plays no part.
- Many simultaneous flows over an uplink between two switches, a switch full of workstations towards the core for example.
- Towards a server with two network cards that speaks LACP itself.
And the counterpart: for pure redundancy between switches, RSTP does the same with fewer moving parts. That second cable is then a spare path that steps in by itself.
A bond in the tool
Bonding lives in the Bridge and ports section, per device. Click the switch in the site, scroll to Bonding and LACP, and add a bond:
| Field | Value | What it does |
|---|---|---|
| Name | bond1 | The interface name everything else refers to |
| Mode | 802.3ad or active-backup | 802.3ad negotiates with the far end, active-backup does not |
| Ports | ether23 and ether24, say | These ports are taken out of the bridge |
| In the bridge | on | The bond itself becomes the bridge port instead of the separate cables |
For 802.3ad the script also sets transmit-hash-policy=layer-2-and-3 and lacp-rate=1sec. The ports you pick as members disappear from the bridge port list automatically; you do not have to do that yourself. A port cannot be a bond member and the emergency port at the same time, and that is an error in the checks.
Do this on both devices. A bond with 802.3ad against a side that does not speak LACP is not a bond, it is a loop.
The limit you have to know
The tool cannot turn a bond into a VLAN trunk. The port assignment in the VLANs section only offers physical ports, so a bond cannot be set to trunk there. If the bond is in the bridge while VLANs are on, it ends up in the script as an untagged access port on the first VLAN in the table, with frame-types=admit-only-untagged-and-priority-tagged. Every tagged frame arriving on it is dropped.
That is exactly wrong for an uplink between two switches, where all VLANs are supposed to pass. You repair it by hand, right after pasting the script, on both devices:
/interface bridge port
set [find interface=bond1] frame-types=admit-only-vlan-tagged ingress-filtering=yes
/interface bridge vlan
set [find vlan-ids=10] tagged=bridge,bond1 untagged=""
set [find vlan-ids=20] tagged=bridge,bond1
set [find vlan-ids=99] tagged=bridge,bond1The first line turns the bond into a trunk. Then you add it to the tagged list per VLAN and take it out of the untagged list of the first VLAN, where the generator had put it. If ordinary access ports also belong on that first VLAN, list them after untagged= instead of leaving it empty. Check the result with /interface bridge vlan print.
Put these lines on the handover sheet. They are not in the generated script, so they are lost the moment somebody generates and pastes again.
The board and the bond
On the network board you draw cables, not bonds. Draw two cables between the same two devices and something other than what you meant happens: both ports become trunks, and the check reports that the second cable makes a loop and that RSTP blocks one of the paths. It works, but it does not add speed.
The practical approach: draw one cable on the board, so the trunks and the port comments are right, and build the bond in the Bridge and ports section of both devices. The second physical cable you plug in on site.
What else to watch
- The same MTU on both sides. The tool compares the MTU per cable and per connected network and reports the difference with the exact port names. For a bond that applies to every member.
- The same speed per member. A bond of a 1G and a 2.5G port is a bond that behaves like two times 1G, with surprises.
- Measure before you build. Is the link really full, or is the complaint something else? See Checks about speed and Wired traffic is slow.
Further reading: Bonding and LACP, Switches in a ring and MTU and jumbo frames.