LFCE 21 🐧 Link Aggregation — Concepts - KandZ

⏱️ Estimated read: 15 min | |

Link aggregation is the practice of combining multiple physical network interfaces into a single logical interface. The purpose is not to make a single file transfer faster—it cannot do that. The purpose is to increase aggregate throughput across many simultaneous flows, and to provide redundancy so that the failure of one cable does not sever connectivity. On Linux, this is implemented by the kernel’s bonding driver, which presents a virtual interface (typically bond0) to the networking stack while distributing traffic across the enslaved physical ports according to a configurable mode .

For the LFCE candidate, link aggregation sits at the intersection of networking and high availability. The exam objectives include maintaining the integrity and availability of hardware and deploying high availability solutions . Link aggregation is one of the most common mechanisms for achieving both at the interface level. Understanding the modes, the switch requirements, and the limitations of aggregation is essential before configuring it.

Key point: Link aggregation increases aggregate bandwidth, not per-flow bandwidth. A single TCP connection between two hosts will traverse one physical link and is limited to that link’s speed. The benefit comes from many flows being distributed across the member links by a hash algorithm. If redundancy is the only goal, a simple active-backup bond requires no switch configuration. If throughput is the goal, the switch must be configured to match, and the traffic must consist of multiple flows .

Why link aggregation exists

The single-link bottleneck problem.

A server with one 1 Gbps interface is limited to 1 Gbps of total network throughput, regardless of how many clients it serves or how much bandwidth the switch can provide. Adding a second physical interface without aggregation does not solve the problem for applications bound to a single IP address, because the kernel will use only one interface for a given destination. Link aggregation presents the two interfaces as one logical interface with one IP address, and distributes flows across both. A server serving many clients can now saturate both links simultaneously, even though no single client receives more than 1 Gbps .

The single-point-of-failure problem.

A server with one cable has one point of failure. If the cable is unplugged, the NIC fails, or the switch port dies, the server is disconnected. A second cable connected to a second switch port does not help unless the kernel knows how to fail over between them. Bonding in active-backup mode monitors the links and switches all traffic to the surviving link when the active one fails. This failover is transparent to applications and requires no routing changes. It is the simplest form of link aggregation and the one that requires the least switch configuration .

The switch-negotiation problem.

Static aggregation (sometimes called mode-on or unconditional trunking) requires the administrator to configure both the server and the switch manually. If the configurations do not match, the result can be a loop, a broadcast storm, or silent packet loss. LACP (Link Aggregation Control Protocol, defined in IEEE 802.1AX) solves this by exchanging control frames between the server and the switch. The two ends negotiate which links belong to the aggregation and verify that the configuration is consistent. If a cable is connected to the wrong port, LACP detects the mismatch and refuses to aggregate that link, preventing the failure that static configuration would cause .

The mode-selection problem.

Linux bonding supports several modes, each with different requirements and behaviors. balance-rr (mode 0) sends packets in round-robin order across all links, which can increase throughput for a single flow but may cause out-of-order delivery and requires switch support. active-backup (mode 1) uses one link at a time and fails over on failure; it requires no switch configuration. 802.3ad (mode 4) implements LACP and requires a switch that supports LACP. balance-xor and balance-tlb/balance-alb provide other trade-offs. Choosing the wrong mode produces either a configuration that does not work or a configuration that works but does not provide the expected benefit .

a. Bonding modes and their requirements

The Linux bonding driver exposes its behavior through the mode parameter. Each mode defines how outgoing traffic is distributed and how failover is handled.

# Load the bonding module
modprobe bonding

# Check available bonding modes in the kernel documentation
modinfo bonding | grep description

The most commonly used modes for LFCE-level configuration are active-backup and 802.3ad. active-backup requires no switch configuration and provides pure redundancy. 802.3ad requires LACP on the switch and provides both redundancy and aggregate throughput. balance-rr is the default mode in many distributions but is rarely the correct choice because it can cause out-of-order packet delivery and requires careful switch configuration .

# Example: create a bond in active-backup mode
# Only one slave is active; the other is standby
ip link add bond0 type bond mode active-backup
ip link set eth0 master bond0
ip link set eth1 master bond0
ip addr add 192.168.1.100/24 dev bond0
ip link set bond0 up

In active-backup, the bond sends traffic through one slave and monitors the other. If the active slave fails, the bond switches to the standby. The MAC address of the bond is the MAC address of the active slave, and the switch sees only one MAC address at a time. No switch configuration is required because the switch does not need to know that two ports belong to the same host .

# Example: create a bond in 802.3ad (LACP) mode
ip link add bond0 type bond mode 802.3ad
ip link set eth0 master bond0
ip link set eth1 master bond0
ip addr add 192.168.1.100/24 dev bond0
ip link set bond0 up

In 802.3ad, the bond and the switch exchange LACPDUs to negotiate the aggregation. The switch must be configured with a matching LACP port channel. Both ends must agree on the aggregation before traffic flows. The bond distributes outgoing traffic across the active links using a hash of the packet headers, and accepts incoming traffic on any active link .

b. The hashing algorithm and per-flow distribution

Link aggregation does not stripe packets across links. It assigns each flow to a single link. A flow is identified by a hash of selected header fields—typically source and destination MAC addresses, and optionally IP addresses and TCP/UDP port numbers. All packets belonging to the same flow traverse the same link, which preserves packet ordering .

# Check the transmit hash policy for an 802.3ad bond
# The policy determines which header fields are used for the hash
cat /sys/class/net/bond0/bonding/xmit_hash_policy
# Common values: layer2, layer2+3, layer3+4

The layer2 policy hashes only MAC addresses. It works well when there are many clients with distinct MAC addresses reaching the server through a switch. The layer3+4 policy includes IP addresses and port numbers, which provides finer distribution when traffic passes through a router (which changes the MAC addresses) or when many flows originate from the same host. The choice of policy affects how evenly traffic is distributed, and therefore how much of the aggregate bandwidth is actually usable .

The fundamental limitation is that a single flow cannot exceed the speed of one link. If a client downloads one large file from a server with a 2×1 Gbps bond, the download is limited to 1 Gbps because the flow is hashed to one link. If ten clients download ten files simultaneously, the flows are distributed across both links, and the aggregate throughput approaches 2 Gbps .

c. Switch requirements and LACP negotiation

The switch configuration depends on the bonding mode. active-backup requires no switch configuration because the switch sees only one active MAC address at a time. 802.3ad requires the switch to be configured with an LACP port channel that includes the ports connected to the bond’s slaves.

# On a Linux switch (bridge), LACP is not natively supported by the bridge driver
# A managed switch or a Linux host running a switching daemon is required
# The switch configuration is vendor-specific
# Cisco example: channel-group 1 mode active
# The "active" mode initiates LACP negotiation

LACP operates in two modes: active and passive. An active port initiates negotiation by sending LACPDUs. A passive port responds to LACPDUs but does not initiate. At least one end must be active. If both ends are passive, the aggregation never forms. In practice, the switch is often configured as active and the server as passive, or both are active .

# Check LACP status on the bond
cat /proc/net/bonding/bond0
# Output includes:
# Bonding Mode: IEEE 802.3ad Dynamic link aggregation
# LACP rate: slow
# Aggregator selection policy: ...
# Slave Interface: eth0
#   MII Status: up
#   LACP status: active

The LACP status field confirms whether the link has been successfully aggregated. If it shows down or no, the switch configuration does not match, or the cable is connected to a port that is not part of the port channel. The bond will not pass traffic on a link that has not been aggregated .

Complete Example Session

# ============================================
# PART 1: CHECK THE AVAILABLE INTERFACES
# ============================================
ip link show
# Identify two physical interfaces that will be enslaved, e.g., eth0 and eth1

# ============================================
# PART 2: LOAD THE BONDING MODULE
# ============================================
modprobe bonding
lsmod | grep bonding
# The module must be loaded before creating a bond interface

# ============================================
# PART 3: CREATE AN ACTIVE-BACKUP BOND
# ============================================
# Active-backup requires no switch configuration
ip link add bond0 type bond mode active-backup
ip link set eth0 master bond0
ip link set eth1 master bond0
ip addr add 192.168.1.100/24 dev bond0
ip link set bond0 up
ip link set eth0 up
ip link set eth1 up

# ============================================
# PART 4: VERIFY THE ACTIVE-BACKUP BOND
# ============================================
cat /proc/net/bonding/bond0
# Output shows:
# Bonding Mode: fault-tolerance (active-backup)
# Currently Active Slave: eth0
# MII Status: up for both slaves

# ============================================
# PART 5: TEST FAILOVER
# ============================================
# Bring down the active slave
ip link set eth0 down
cat /proc/net/bonding/bond0
# Output shows: Currently Active Slave: eth1
# Traffic continues through eth1

# Bring the original slave back up
ip link set eth0 up
# eth0 becomes the standby; eth1 remains active

# ============================================
# PART 6: DELETE AND RECREATE AS 802.3ad
# ============================================
ip link set eth0 nomaster
ip link set eth1 nomaster
ip link delete bond0

ip link add bond0 type bond mode 802.3ad
ip link set eth0 master bond0
ip link set eth1 master bond0
ip addr add 192.168.1.100/24 dev bond0
ip link set bond0 up
ip link set eth0 up
ip link set eth1 up

# ============================================
# PART 7: VERIFY LACP NEGOTIATION
# ============================================
cat /proc/net/bonding/bond0
# Output includes:
# Bonding Mode: IEEE 802.3ad Dynamic link aggregation
# LACP status: active for each slave (if switch is configured)
# If LACP status is "down", the switch port channel is missing or mismatched

# ============================================
# PART 8: CHECK THE HASH POLICY
# ============================================
cat /sys/class/net/bond0/bonding/xmit_hash_policy
# Default is often layer2
# For routed traffic, layer3+4 may provide better distribution
echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

# ============================================
# PART 9: TEST AGGREGATE THROUGHPUT
# ============================================
# From multiple clients simultaneously:
# iperf3 -c 192.168.1.100 -t 10
# Aggregate throughput should approach the sum of the link speeds
# A single client will be limited to one link's speed

# ============================================
# PART 10: PERSISTENCE
# ============================================
# The bond configuration must be written to the network manager
# Example with nmcli:
nmcli connection add type bond con-name bond0 ifname bond0 \
  bond.options "mode=active-backup"
nmcli connection add type ethernet con-name bond0-port1 ifname eth0 controller bond0
nmcli connection add type ethernet con-name bond0-port2 ifname eth1 controller bond0
nmcli connection up bond0

The ten parts demonstrate the complete lifecycle: load the module, create an active-backup bond, verify failover, recreate as LACP, verify negotiation, check the hash policy, and persist the configuration. The active-backup test in Parts 3–5 shows failover without any switch configuration. The LACP test in Parts 6–7 requires a matching switch configuration that is not shown because it is vendor-specific.

Quick Reference

Bonding Modes

Mode	Name	Switch Requirement	Purpose
0	balance-rr	Static EtherChannel/trunk	Round-robin; may reorder packets
1	active-backup	None	Redundancy only
2	balance-xor	Static EtherChannel/trunk	Hash-based load balancing
4	802.3ad	LACP port channel	Dynamic LACP; redundancy + throughput
5	balance-tlb	None (driver support)	Adaptive transmit load balancing
6	balance-alb	None (driver support)	Adaptive load balancing

Key Files and Commands

Task	Command/File
Load module	`modprobe bonding`
Create bond	`ip link add bond0 type bond mode <mode>`
Enslave port	`ip link set eth0 master bond0`
Show bond status	`cat /proc/net/bonding/bond0`
Check hash policy	`cat /sys/class/net/bond0/bonding/xmit_hash_policy`
Set hash policy	`echo layer3+4 > .../xmit_hash_policy`

LACP Status Indicators

Indicator	Meaning
`LACP status: active`	Link aggregated successfully
`LACP status: down`	Switch port channel missing or mismatched
`Currently Active Slave`	The slave carrying traffic (active-backup)

Best Practices

✅ Do This:

# Use active-backup when no switch configuration is possible
ip link add bond0 type bond mode active-backup                 # ✅

# Use 802.3ad when the switch supports LACP
ip link add bond0 type bond mode 802.3ad                       # ✅

# Verify LACP status after configuration
cat /proc/net/bonding/bond0 | grep "LACP status"               # ✅

# Choose the hash policy based on traffic patterns
echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy  # ✅

# Test failover by bringing down the active slave
ip link set eth0 down; cat /proc/net/bonding/bond0              # ✅

# Persist through the network manager
nmcli connection add type bond ...                             # ✅

❌ Don’t Do This:

# Expect a single flow to use multiple links
# A single TCP connection is limited to one link                    # ❌

# Use 802.3ad without configuring the switch
# LACP negotiation fails; bond does not pass traffic                # ❌

# Assume balance-rr works with any switch
# It may cause loops or out-of-order packets without proper config # ❌

# Use active-backup for throughput
# Only one link is active at a time                                # ❌

# Forget to load the bonding module
modprobe bonding    # Required before creating a bond             # ❌

# Ignore the hash policy for routed traffic
# layer2 may not distribute flows well through a router             # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Bond created but no traffic	Switch port channel missing for 802.3ad	Configure LACP on switch
Failover does not occur	Link monitoring not configured	Check `miimon` or `arp_interval`
Single flow slower than expected	Per-flow hashing limits to one link	Expected; aggregate benefits require many flows
LACP status down	Cable on wrong port or switch mismatch	Verify switch port channel includes correct ports
Bond lost after reboot	`ip link add` is not persistent	Configure through nmcli/Netplan
Packets out of order	`balance-rr` used with TCP	Use 802.3ad or active-backup

Real-World Examples

1. Active-backup bond

ip link add bond0 type bond mode active-backup
ip link set eth0 master bond0
ip link set eth1 master bond0

2. LACP bond

ip link add bond0 type bond mode 802.3ad
ip link set eth0 master bond0
ip link set eth1 master bond0

3. Check active slave

cat /proc/net/bonding/bond0 | grep "Currently Active"

4. Test failover

ip link set eth0 down
cat /proc/net/bonding/bond0 | grep "Currently Active"

5. Check LACP status

cat /proc/net/bonding/bond0 | grep "LACP status"

6. Set hash policy

echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

7. Set MII monitoring interval

ip link set bond0 type bond miimon 100

8. Persist with nmcli

nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup"

9. Add port with nmcli

nmcli connection add type ethernet con-name bond0-port1 ifname eth0 controller bond0

10. Delete bond

ip link set eth0 nomaster
ip link set eth1 nomaster
ip link delete bond0

Visual

Active-Backup vs 802.3ad

┌──────────────────────────────────────────────────────────────┐
│  TWO BONDING MODES, TWO BEHAVIORS                            │
│                                                              │
│  ACTIVE-BACKUP (mode 1):                                     │
│  ┌────────┐                                                  │
│  │ eth0   │──── ACTIVE ────▶ Switch (no config needed)       │
│  └────────┘                                                  │
│  ┌────────┐                                                  │
│  │ eth1   │──── STANDBY ──▶ (no traffic)                    │
│  └────────┘                                                  │
│                                                              │
│  Only one link carries traffic. Failover is transparent.     │
│  No switch configuration required.                           │
│                                                              │
│  802.3ad (mode 4):                                           │
│  ┌────────┐                                                  │
│  │ eth0   │──── ACTIVE ────▶ Switch (LACP port channel)      │
│  └────────┘                     │                            │
│  ┌────────┐                     │                            │
│  │ eth1   │──── ACTIVE ────▶     │                            │
│  └────────┘                     ▼                            │
│                            Traffic distributed              │
│                            by hash across both              │
│                                                              │
│  Both links carry traffic. LACP negotiation required.        │
└──────────────────────────────────────────────────────────────┘

Per-Flow Hashing

┌──────────────────────────────────────────────────────────────┐
│  FLOWS ARE HASHED TO LINKS, NOT STRIPED                     │
│                                                              │
│  Flow A (client 1) ──▶ hash ──▶ eth0                        │
│  Flow B (client 2) ──▶ hash ──▶ eth1                        │
│  Flow C (client 3) ──▶ hash ──▶ eth0                        │
│  Flow D (client 4) ──▶ hash ──▶ eth1                        │
│                                                              │
│  Each flow uses one link. Packets within a flow stay in      │
│  order. Aggregate throughput approaches 2× link speed.       │
│                                                              │
│  Single large flow:                                          │
│  Flow E (one client) ──▶ hash ──▶ eth0 (only)               │
│  Throughput limited to 1× link speed.                        │
└──────────────────────────────────────────────────────────────┘

LACP Negotiation

┌──────────────────────────────────────────────────────────────┐
│  LACP EXCHANGES CONTROL FRAMES BEFORE AGGREGATING            │
│                                                              │
│  Server                          Switch                      │
│  ┌────────┐                     ┌────────┐                   │
│  │ eth0   │──── LACPDU ────────▶│ Port 1 │                   │
│  │        │◀─── LACPDU ─────────│        │                   │
│  └────────┘                     └────────┘                   │
│  ┌────────┐                     ┌────────┐                   │
│  │ eth1   │──── LACPDU ────────▶│ Port 2 │                   │
│  │        │◀─── LACPDU ─────────│        │                   │
│  └────────┘                     └────────┘                   │
│                                                              │
│  If both ends agree, the links are aggregated.               │
│  If a cable is on the wrong port, LACP refuses to aggregate. │
│  This prevents loops and misconfigurations.                  │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Linux implementation	Bonding driver (`bond0`)
Modes	active-backup (1), 802.3ad (4), balance-rr (0), others
Active-backup requirement	No switch configuration
802.3ad requirement	LACP port channel on switch
Per-flow bandwidth	Limited to one link
Aggregate bandwidth	Sum of active links for multiple flows
Hash policy	`layer2`, `layer2+3`, `layer3+4`
LACP status	`cat /proc/net/bonding/bond0`
Failover monitoring	`miimon` (link state) or `arp_interval`
Persistence	nmcli, Netplan, or network config files

Key takeaways:

Link aggregation increases aggregate bandwidth, not per-flow bandwidth. A single TCP connection is hashed to one physical link and is limited to that link’s speed. The benefit comes from many flows being distributed across the member links .
Active-backup requires no switch configuration. Only one link is active at a time. The switch sees one MAC address. Failover is transparent. This is the correct mode when redundancy is the goal and switch access is limited .
802.3ad requires LACP on the switch. Both ends must negotiate the aggregation. If the switch is not configured, the bond does not pass traffic on the unaggregated links. LACP prevents loops and misconfigurations that static aggregation would allow .
The hash policy determines distribution. layer2 hashes MAC addresses and works well with many clients behind a switch. layer3+4 includes IP addresses and ports and provides finer distribution through routers. The choice affects how much of the aggregate bandwidth is usable .
/proc/net/bonding/bond0 is the verification file. It shows the mode, the active slave (in active-backup), the LACP status (in 802.3ad), and the link state of each slave. If the mode is 802.3ad and LACP status is not active, the switch configuration is wrong .
Persistence is separate from the running configuration. ip link add bond0 creates a bond that disappears on reboot. NetworkManager, Netplan, or distribution-specific configuration files must be used to recreate it at boot.

Remember: Link aggregation is not a faster cable. It is a bundle of cables treated as one logical interface, with traffic distributed by a hash that keeps each flow on a single link. If you need redundancy without switch changes, use active-backup. If you need aggregate throughput and control the switch, use 802.3ad with LACP. Verify with /proc/net/bonding/bond0, test failover by bringing a link down, and persist through the network manager. A bond that appears in ip link but has no active LACP negotiation is a bond that looks configured but carries no traffic.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!