How to Configure Network Bonding and Teaming on RHEL 7

Network link aggregation allows multiple physical network interfaces to be combined into a single logical interface, providing increased throughput and fault tolerance. RHEL 7 supports two distinct kernel-level mechanisms for achieving this: the older bonding driver, which has been part of the Linux kernel for over two decades, and the newer Network Teaming subsystem, introduced as a more modular and extensible alternative. Both approaches deliver the same end result — a resilient, aggregated network interface — but differ significantly in their architecture and tooling. This tutorial covers configuring both methods, explains the available bonding modes, and helps you choose the right approach for your environment.

Prerequisites

  • RHEL 7 system with root or sudo access
  • Two or more physical network interfaces (e.g., ens33, ens34)
  • NetworkManager running (systemctl status NetworkManager)
  • For 802.3ad LACP bonding: a managed switch that supports LACP (IEEE 802.3ad)
  • For Network Teaming: the teamd package installed

Step 1: Understand Bonding Modes

The Linux bonding driver supports seven modes. Each mode trades off between bandwidth aggregation and fault tolerance:

  • mode 0 — balance-rr (Round Robin): Packets are transmitted sequentially across all slave interfaces. Provides load balancing and fault tolerance. Requires switch-side configuration (EtherChannel or similar) to avoid out-of-order packet issues.
  • mode 1 — active-backup: Only one slave is active at a time. The backup slave takes over if the active fails. No switch configuration required; safest general-purpose mode.
  • mode 2 — balance-xor: XOR of source and destination MAC/IP is used to select the transmit slave. Provides load balancing; requires switch EtherChannel.
  • mode 3 — broadcast: All packets are transmitted on all slave interfaces. Used for fault tolerance in special scenarios (e.g., dual ISP with asymmetric routing).
  • mode 4 — 802.3ad (LACP): IEEE Link Aggregation Control Protocol. Creates aggregated groups that share the same speed and duplex. Requires a switch that supports 802.3ad LACP. Most common in enterprise environments.
  • mode 5 — balance-tlb (Adaptive Transmit Load Balancing): Distributes outbound traffic according to current load on each slave. No switch support required; incoming traffic arrives on the current active slave.
  • mode 6 — balance-alb (Adaptive Load Balancing): Extends balance-tlb with receive load balancing using ARP negotiation. No special switch support required.

Step 2: Configure Network Bonding with nmcli

NetworkManager’s nmcli command-line tool is the preferred way to configure bonding on RHEL 7, as it writes the correct ifcfg files and handles interaction with the bonding kernel module automatically.

Create the Bond Master Interface

# Create bond0 using active-backup mode (mode 1)
nmcli con add type bond 
    con-name bond0 
    ifname bond0 
    bond.options "mode=active-backup,miimon=100"

# Assign an IP address to the bond interface
nmcli con modify bond0 
    ipv4.addresses "192.168.1.10/24" 
    ipv4.gateway "192.168.1.1" 
    ipv4.dns "8.8.8.8" 
    ipv4.method manual

Add Slave Interfaces to the Bond

# Add ens33 as the first slave
nmcli con add type bond-slave 
    con-name bond0-slave-ens33 
    ifname ens33 
    master bond0

# Add ens34 as the second slave
nmcli con add type bond-slave 
    con-name bond0-slave-ens34 
    ifname ens34 
    master bond0

Bring Up the Bond

# Bring up the slave interfaces first
nmcli con up bond0-slave-ens33
nmcli con up bond0-slave-ens34

# Bring up the bond master
nmcli con up bond0

# Verify the bond is active
ip addr show bond0
cat /proc/net/bonding/bond0

Step 3: Configure 802.3ad LACP Bonding

For environments where the upstream switch supports LACP, mode 4 (802.3ad) provides true bidirectional load balancing negotiated by the protocol rather than heuristics.

# Create bond0 in 802.3ad mode
# miimon=100 checks link state every 100ms
# lacp_rate=fast requests LACP PDUs every second
nmcli con add type bond 
    con-name bond0-lacp 
    ifname bond0 
    bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"

# Add slaves (same as before)
nmcli con add type bond-slave con-name bond0-slave-ens33 ifname ens33 master bond0
nmcli con add type bond-slave con-name bond0-slave-ens34 ifname ens34 master bond0

# Assign IP
nmcli con modify bond0-lacp 
    ipv4.addresses "192.168.1.10/24" 
    ipv4.gateway "192.168.1.1" 
    ipv4.method manual

nmcli con up bond0-slave-ens33
nmcli con up bond0-slave-ens34
nmcli con up bond0-lacp

The xmit_hash_policy=layer3+4 option uses source and destination IP addresses along with TCP/UDP port numbers to distribute flows across slaves, providing better load distribution than the default MAC-based policy.

Step 4: Load the Bonding Module and Verify ifcfg Files

The bonding kernel module is typically loaded automatically by NetworkManager. If it is not loaded, add a persistent module configuration.

# Manually load the bonding module if needed
modprobe bonding

# Persist module load at boot
echo "bonding" > /etc/modules-load.d/bonding.conf

# Inspect the generated ifcfg file for the bond master
cat /etc/sysconfig/network-scripts/ifcfg-bond0

# Expected output includes:
# DEVICE=bond0
# BONDING_MASTER=yes
# TYPE=Bond
# BONDING_OPTS="mode=active-backup miimon=100"
# BOOTPROTO=none
# IPADDR=192.168.1.10
# PREFIX=24

# Check the slave ifcfg file
cat /etc/sysconfig/network-scripts/ifcfg-bond0-slave-ens33

Step 5: Configure Network Teaming (Alternative to Bonding)

Network Teaming (teamd) is implemented as a user-space daemon that communicates with the kernel via a Netlink interface. It supports the same link aggregation scenarios as bonding but uses a JSON-based configuration and offers per-runner plugin architecture.

Install teamd

yum install -y teamd

Create a Team Interface with nmcli

# Create team0 using the activebackup runner
nmcli con add type team 
    con-name team0 
    ifname team0 
    team.config '{"runner":{"name":"activebackup"},"link_watch":{"name":"ethtool"}}'

# Assign an IP address
nmcli con modify team0 
    ipv4.addresses "192.168.1.20/24" 
    ipv4.gateway "192.168.1.1" 
    ipv4.method manual

# Add slave ports to the team
nmcli con add type team-slave 
    con-name team0-slave-ens33 
    ifname ens33 
    master team0

nmcli con add type team-slave 
    con-name team0-slave-ens34 
    ifname ens34 
    master team0

# Bring up the team
nmcli con up team0-slave-ens33
nmcli con up team0-slave-ens34
nmcli con up team0

Configure LACP Teaming (roundrobin runner)

# LACP-style teaming using the lacp runner
nmcli con add type team 
    con-name team0-lacp 
    ifname team0 
    team.config '{"runner":{"name":"lacp","active":true,"fast_rate":true},"link_watch":{"name":"ethtool"}}'

Step 6: Monitor Team Status with teamdctl

The teamdctl utility queries the running teamd daemon and displays rich JSON state information about the team interface and its ports.

# Show overall team status in human-readable form
teamdctl team0 state

# Show detailed JSON state
teamdctl team0 state view

# Show the active port
teamdctl team0 state item get runner.active_port

# Watch for port link changes
journalctl -u NetworkManager -f | grep team0

# Simulate a link failure and verify failover
ip link set ens33 down
teamdctl team0 state
ip link set ens33 up

Step 7: Verify Bonding or Teaming Operation

# For bonding: check the kernel bonding status file
cat /proc/net/bonding/bond0

# For teaming: show interface stats
ip -s link show team0

# Test failover: bring down the active slave and verify traffic continues
# (run a continuous ping first: ping -I bond0 192.168.1.1)
ip link set ens33 down
# Ping should continue without interruption
ip link set ens33 up

Step 8: Bonding vs Network Teaming — Comparison

  • Architecture — Bonding is a kernel-only driver; teaming uses a user-space daemon (teamd) plus a thin kernel module, making teamd behavior inspectable and configurable at runtime.
  • Configuration — Bonding options are set as module parameters or BONDING_OPTS strings; teaming uses structured JSON, which is easier to validate programmatically.
  • Runners — Teaming supports pluggable runners: activebackup, roundrobin, lacp, broadcast, loadbalance, and random. New runners can be written without modifying kernel code.
  • Link watch — Teaming supports ethtool, arp_ping, and nsna_ping link watchers independently per port. Bonding has a single global MII or ARP monitor.
  • Performance — Bonding has slightly lower overhead because all logic runs in the kernel. Teaming’s user-space daemon adds a small latency penalty that is negligible for most workloads.
  • Red Hat recommendation — Red Hat recommends Network Teaming as the preferred method for RHEL 7 and later, though bonding remains fully supported and is preferable in containerized or minimal environments where user-space daemons are undesirable.

Conclusion

You have configured network bonding in active-backup and 802.3ad LACP modes using nmcli, inspected the generated ifcfg configuration files under /etc/sysconfig/network-scripts/, and built an equivalent teamed interface using the teamd daemon with the activebackup and lacp runners. Both approaches produce a resilient logical interface that survives individual link failures transparently, protecting application connectivity during switch port failures, cable faults, or NIC hardware issues. Choosing between bonding and teaming comes down to operational preference: bonding is simpler and ubiquitous, while teaming provides a richer feature set and cleaner runtime introspection via teamdctl. Either way, link aggregation is a fundamental building block of high-availability Linux network infrastructure.