A serious server does not hang on a single cable: bonding aggregates two physical links into a single fault-tolerant interface, and the bridge turns it into a software switch for your virtual machines. This guide configures both on Linux with netplan: a bond in active-backup mode (redundancy), then a bridge on top. You check the aggregation with /proc/net/bonding, and you prove the failover by cutting the active link: traffic carries on over the other one. All outputs come from a real lab (Ubuntu 24.04, two dedicated links). Audience: administrators building a redundant server or a virtualisation host.
Bonding and bridging are LFCS objectives (the Networking domain). This guide puts them into practice end to end.
What you will learn
- Tell a bond (link aggregation) from a bridge (software switch).
- Create a bond in active-backup mode with netplan.
- Put a bridge on top of the bond, to plug VMs into it.
- Check the state with
/proc/net/bondingandip. - Prove fault tolerance with a real failover.
Prerequisites
- A Linux server with at least three interfaces: one for administration (here
eth0, which carries SSH and which you leave alone), and two links to aggregate (hereens19andens20). - netplan (Ubuntu 18.04+, Debian with netplan). The
NetworkManager/nmcli(RHEL) andsystemd-networkdequivalents are pointed out. sudorights.
Bond and bridge: two different building blocks
They are often confused, although they answer two opposite needs:
- A bond (or bonding, link aggregation) merges several physical links into a single logical interface. Goal: redundancy (if a cable or a switch fails, the other one takes over) or throughput (adding up bandwidth). It acts downwards, on the hardware side.
- A bridge is a software network switch: it connects several interfaces (physical, VMs, containers) on the same segment. Goal: give network access to virtual machines. It acts upwards, on the machine side.
The two combine: a bond for redundancy underneath, a bridge on the bond to plug the VMs in on top. It is the classic network architecture of a virtualisation host.
Choose the bond mode
The mode determines how the links cooperate. Three are common:
| Mode | Behaviour | When |
|---|---|---|
| active-backup (mode 1) | One active link, the other on standby | Simple redundancy, no switch-side setting |
| 802.3ad (mode 4, LACP) | Links add up, negotiated through LACP | Throughput + redundancy, LACP-capable switch required |
| balance-rr (mode 0) | Packet-by-packet distribution | Maximum throughput, but risk of out-of-order packets |
This guide uses active-backup: it is the most robust and the only one that needs no configuration on the switch on the other side. Perfect to protect yourself from a switch or cable failure.
Configure the bond with netplan
Create a dedicated netplan file (without touching the cloud-init one that handles administration). It declares the two links, the bond, then the bridge.
network: version: 2 ethernets: ens19: dhcp4: false ens20: dhcp4: false bonds: bond0: interfaces: [ens19, ens20] parameters: mode: active-backup primary: ens19 mii-monitor-interval: 100 bridges: br0: interfaces: [bond0] addresses: [10.10.0.1/24]Two parameters deserve a word. primary: ens19 names the preferred link: it takes over again as soon as it comes back. mii-monitor-interval: 100 tells the kernel to monitor the state of the links every 100 ms; it is what allows a fast failover.
Apply the configuration:
sudo netplan applyCheck the aggregation
A look at the interfaces shows the full hierarchy: two slaves, a master, a bridge.
ip -br link showeth0 UP bc:24:11:1e:d3:37 <BROADCAST,MULTICAST,UP,LOWER_UP>ens19 UP aa:06:70:cb:79:2d <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>ens20 UP aa:06:70:cb:79:2d <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>bond0 UP aa:06:70:cb:79:2d <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>br0 UP 86:2d:8f:28:10:2b <BROADCAST,MULTICAST,UP,LOWER_UP>Note that ens19 and ens20 share the same MAC address (aa:06:...), the one of the bond: from the outside, the two links form a single interface. The details live in a kernel file:
cat /proc/net/bonding/bond0Bonding Mode: fault-tolerance (active-backup)Primary Slave: ens19 (primary_reselect always)Currently Active Slave: ens19MII Status: upSlave Interface: ens20 MII Status: upSlave Interface: ens19 MII Status: upThe mode is confirmed (active-backup), the active link is ens19, and both slaves are healthy (MII Status: up). The br0 bridge, for its part, carries the IP address:
ip -br addr show br0br0 UP 10.10.0.1/24 ...Prove fault tolerance
This is the test that matters: what happens if a link goes down? Let us simulate the failure of the active link.
sudo ip link set ens19 downThe kernel detects the loss in less than 100 ms and fails over to the standby link:
cat /proc/net/bonding/bond0Currently Active Slave: ens20Slave Interface: ens20 MII Status: upSlave Interface: ens19 MII Status: downThe active link became ens20, ens19 is down, and above all the bond stays UP:
ip -br link show bond0bond0 UP aa:06:70:cb:79:2d <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>No service interruption: the traffic simply moved to the other cable. When ens19 comes back, it takes over again (thanks to primary):
sudo ip link set ens19 up# Currently Active Slave: ens19That is the whole value of the bond: a failure of a cable, a switch port or a card becomes invisible to the services.
On RHEL, AlmaLinux and Rocky
The Red Hat family manages the network with NetworkManager. The same aggregation is created with nmcli:
sudo nmcli connection add type bond ifname bond0 con-name bond0 bond.options "mode=active-backup,miimon=100"sudo nmcli connection add type ethernet ifname ens19 con-name bond0-port1 controller bond0sudo nmcli connection add type ethernet ifname ens20 con-name bond0-port2 controller bond0sudo nmcli connection add type bridge ifname br0 con-name br0 ipv4.method manual ipv4.addresses 10.10.0.1/24sudo nmcli connection modify bond0 controller br0 port-type bridgeThe concept is identical: two slaves, a bond, a bridge. Only the configuration tool changes; /proc/net/bonding/bond0 remains the source of truth. The old master and slave-type keywords are still accepted by nmcli 1.56 (AlmaLinux 10) and produce the same profile, but they have disappeared from its help: write controller and port-type. Without con-name, nmcli names the port itself bond-slave-ens19, less readable when troubleshooting.
Security and points of attention
The danger of a bond is not an attack, it is losing access: you change the network configuration of the machine from the network itself. The first two points below protect your access, the last two avoid the silent outage, the one where the redundancy you believe you have has not existed for weeks.
- Keep an administration interface out of the bond: it saves you if the network configuration goes wrong.
- Check the mode on the switch side:
802.3adrequires LACP configured on the other side, otherwise the link remains unusable.active-backuphas no such constraint. - Test the failover before production: a bond that has never failed over is a bond you do not know will fail over.
- Watch
/proc/net/bonding: a slave silently inMII Status: downleaves you without redundancy without knowing it.
Troubleshooting
A bond that does not work is almost always diagnosed in the same place: /proc/net/bonding/bond0, which gives the active mode and the state of each slave. Look at this file before changing the configuration. The table then links the visible symptoms to the most frequent causes, two of which belong to the switch on the other side and not to the server.
| Symptom | Probable cause | Solution |
|---|---|---|
The bond stays DOWN | No slave up, or switch expecting LACP | Check /proc/net/bonding, switch to active-backup |
Loss of control after netplan apply | SSH interface included in the bond | Start again from the console, take the admin interface out |
| No failover when the cable is cut | mii-monitor-interval missing | Add mii-monitor-interval: 100 |
802.3ad unusable, not just without extra throughput | LACP not negotiated on the switch side: each port gets its own aggregator (different Aggregator ID) and goes to MII Status: down, while the bond itself shows up | Configure the port-channel on the switch, or switch to active-backup |
The bond is up but Currently Active Slave: None after an nmcli con up <bond> | Reactivating the controller detaches the ports | Reactivate each port afterwards; nmcli announces it in its own way with Connection successfully activated (controller waiting for ports) |
| A freshly created bridge passes nothing for about thirty seconds | STP: the port goes through listening then learning before forwarding, that is twice forward-delay (15 s each) | Wait, or disable STP with bridge.stp no if the topology allows it (forwarding reached in 2 s) |
| The interface enrolled in a bridge lost its IP configuration | NetworkManager removes the [ipv4] section from the port keyfile | Normal: the address now lives on the bridge. nmcli -f ipv4.method con show <port> returns nothing any more |
| The bridge does not pass traffic | bond0 not a member of the bridge | Check interfaces: [bond0] under bridges |
Put it into practice
A bond that has never failed over before your eyes remains a promise on paper. The lab takes up the scenario on the Red Hat side: you build an active-backup bond under a bridge with nmcli, then you cut the active link and watch the failover in /proc/net/bonding.
Key points
- A bond aggregates physical links (redundancy/throughput); a bridge is a software switch for VMs. The two combine.
- active-backup is the most robust mode: redundancy with no switch-side setting.
- netplan declares everything in one file;
/proc/net/bonding/bond0is the source of truth for the state. - The failover is proven by cutting the active link: the standby link takes over, the bond stays UP.
primarymakes the preferred link take over again;mii-monitor-intervalconditions the detection speed.- Never put the administration interface in the bond before the configuration is validated.
Knowledge check
Check that the essentials of this guide stuck. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Diagnose a network problem on Linux
A new full quiz with random questions
Work again only on the questions you missed