You have two cables, one IP, and a headache
You have a Fedora server with two ethernet ports. You plugged both in. You expected the system to use them together. Instead, ip addr shows two separate interfaces, each fighting for the same subnet, or one sits idle while the other maxes out at 1Gbps. You tried to find the configuration files and discovered /etc/sysconfig/network-scripts/ is gone or empty. Fedora uses NetworkManager to manage connections, and the old text-file approach is deprecated. You need to create a bond interface. Bonding lets the kernel treat multiple physical links as one. This gives you redundancy if a cable fails, or more bandwidth if your switch supports it. This guide walks through setting up a bond using nmcli, the command-line interface for NetworkManager.
What's actually happening
Network bonding creates a virtual interface, usually named bond0. This interface holds the IP address, the gateway, and the DNS settings. The physical interfaces become slaves. They lose their individual IP configuration. The kernel routes traffic through the bond. The bond driver decides which slave sends each packet based on the mode. The bond driver also monitors link state. If a slave link goes down, the driver stops sending traffic to it and moves to another slave. The transition happens at the kernel level. Applications see no interruption.
NetworkManager manages the bond connection and the slave connections. When you activate the bond, NetworkManager activates the slaves automatically. The configuration lives in keyfiles in /etc/NetworkManager/system-connections/. You interact with these files through nmcli. Direct edits are possible but risky. nmcli ensures the internal state matches the files. Trust the package manager and the tooling. Manual file edits drift, snapshots stay.
Bonding modes and trade-offs
The mode determines how the bond behaves. Pick the mode before you create the connection. Changing the mode later requires recreating the bond or modifying the options carefully.
Active-backup uses one interface at a time. The other interfaces sit idle until a failure occurs. This mode provides redundancy without any switch configuration. Bandwidth does not increase. Failover time depends on the monitoring interval.
802.3ad, also known as LACP, bundles the links to increase throughput. The switch must support LACP and be configured to match. The bond negotiates with the switch. If the switch is not configured, the bond will fail to establish links. This mode provides both redundancy and bandwidth aggregation.
Balance-rr sends packets in round-robin fashion across all slaves. This increases bandwidth. The switch must support static link aggregation. This mode can cause packet reordering. Applications that rely on packet order may break. Use this mode only if you understand the implications.
Broadcast sends every packet out all interfaces. This provides extreme redundancy but wastes bandwidth. Use this mode only for specific high-availability setups where the receiver can handle duplicate packets.
Configuring the bond with nmcli
Run these commands as root. If you are configuring a remote server, ensure you have a backup access method. A misconfiguration can drop your SSH session. Snapshot the system before the upgrade. Future-you will thank you.
First, identify your physical interfaces. Fedora uses predictable interface names. The names might look like enp3s0 or ens18. Do not assume eth0.
ip link show # List all interfaces to find the names of your physical ports
Create the bond connection. Specify the mode and the monitoring interval. The miimon parameter sets how often the kernel checks the link state. A value of 100 means 100 milliseconds. Lower values detect failures faster but use more CPU.
nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup miimon 100 # Create bond interface with active-backup mode and 100ms monitoring
Assign the IP configuration to the bond. Never assign an IP to the slave interfaces. The bond owns the network identity.
nmcli connection modify bond0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 # Set static IP on bond, replace with your subnet details
nmcli connection modify bond0 ipv4.dns "8.8.8.8 8.8.4.4" # Configure DNS resolvers for the bond connection
Add the physical interfaces as slaves. NetworkManager will create separate connection profiles for each slave. These profiles link the physical interface to the bond.
nmcli connection add type ethernet con-name bond0-slave1 ifname enp3s0 master bond0 # Attach first interface as slave, replace enp3s0 with your interface
nmcli connection add type ethernet con-name bond0-slave2 ifname enp3s1 master bond0 # Attach second interface as slave, replace enp3s1 with your interface
Activate the bond. NetworkManager will bring up the bond and automatically activate the slave connections. You do not need to run up on the slaves.
nmcli connection up bond0 # Activate bond and slaves, NetworkManager handles the dependency chain
Verifying the bond and testing failover
Check the kernel bond status. This file shows the real state of the bond, independent of NetworkManager.
cat /proc/net/bonding/bond0 # Read kernel bond status, shows active slave, link state, and mode details
Look for the Slave Interface section. The active slave will show link status: up. The backup slave will show link status: up but won't be marked as active in active-backup mode.
Verify NetworkManager sees the connection as active.
nmcli connection show bond0 # Confirm connection state is 'connected' and IP is assigned
ip addr show bond0 # Verify the bond interface has the IP address and is UP
Test failover. Unplug one cable. Check the bond status again. The active slave should switch.
cat /proc/net/bonding/bond0 | grep -A 5 "Slave Interface" # Check which slave is now active after unplugging a cable
Reboot before you debug. Half the time the symptom is gone. If the bond does not survive a reboot, the connection autoconnect is disabled. Run nmcli connection modify bond0 connection.autoconnect yes.
Common pitfalls and error messages
Bonding fails when the configuration does not match the hardware or the switch.
If you see LACP negotiation failed, the switch is not configured for LACP. Check the switch settings. The bond mode must match the switch mode.
[FAILED] Failed to start NetworkManager-wait-online.service.
# Or in journalctl:
# bond0: LACP negotiation failed on enp3s0
If the bond comes up but you have no connectivity, check the IP configuration. Ensure the IP is on the bond, not the slaves. Slaves should have no IP address.
If nmcli complains about the interface being enslaved, you tried to activate a slave connection directly. Activate the bond only. NetworkManager manages the slaves.
Convention aside: journalctl -xeu NetworkManager shows detailed logs. The x flag adds explanatory text. The e flag jumps to the end. Use this when the bond fails to start. Look for errors related to the slave interfaces. Run journalctl first. Read the actual error before guessing.
When to use bonding vs alternatives
Use active-backup when you need redundancy and cannot configure the switch. Use 802.3ad when you need increased bandwidth and have a switch that supports LACP. Use balance-rr only when you have a switch configured for static aggregation and your application tolerates packet reordering. Avoid balance-tlb and balance-alb for server workloads. These modes can cause ARP issues and are rarely supported by modern switches. Use a hardware load balancer when you need to distribute traffic across multiple servers. Bonding aggregates links on a single host. It does not balance load across multiple hosts.