Link Aggregation Control Protocol (LACP), defined in IEEE 802.3ad (now 802.1AX), combines multiple physical network interfaces into a single logical bond for increased bandwidth and redundancy. Self-hosting LACP configuration gives you control over link aggregation without relying on managed switch auto-configuration or proprietary vendor tools.
This guide compares three approaches for managing LACP bonds on Linux: systemd networkd, NetworkManager, and iproute2 (manual tc/ip commands).
What Is LACP and Why Use It?
LACP (Link Aggregation Control Protocol) dynamically negotiates link aggregation between a host and a managed switch, providing:
- Increased bandwidth: Aggregate throughput across multiple physical links (e.g., 2×1Gbps = 2Gbps logical)
- Fault tolerance: Automatic failover when a physical link fails
- Load balancing: Traffic distribution across member links using hash-based algorithms
- Dynamic negotiation: LACPDU packets verify link health and negotiate aggregation parameters
Key use cases include server uplinks, storage network connections, virtualization host networking, and any scenario where link redundancy and bandwidth scaling are critical.
systemd networkd
systemd networkd is the network configuration daemon included with systemd. It provides declarative bond configuration through .netdev and .network files, making it ideal for servers already running systemd.
GitHub: systemd/systemd — ⭐16,307 | Last updated: May 2026 | Language: C
Key Features
- Declarative configuration: Bond settings defined in unit files
- LACP support: Full 802.3ad bond mode with configurable transmit policies
- Integration with systemd: Unified management via
systemctl - No external dependencies: Ships with systemd on most distributions
- Link health monitoring: Built-in carrier and link state tracking
Configuration
| |
Activation
| |
NetworkManager
NetworkManager is the default network management daemon for most desktop Linux distributions and increasingly adopted on servers. It provides both CLI (nmcli) and GUI (nm-connection-editor) interfaces for bond management.
GitHub: NetworkManager/NetworkManager — actively maintained | Language: C
Key Features
- nmcli CLI: Full scripting interface for automated configuration
- LACP modes: 802.3ad (mode 4) with all standard options
- Connection profiles: Save and switch between bond configurations
- D-Bus API: Programmatic control from applications and orchestration tools
- Broad hardware support: Works with virtually all Linux network drivers
Configuration via nmcli
| |
Persistent Configuration (Keyfile)
| |
iproute2 (Manual Configuration)
iproute2 provides the ip command suite for direct kernel-level network configuration. Manual bond setup gives maximum control and works on any Linux distribution without requiring a network management daemon.
GitHub: shemminger/iproute2 — ⭐968 | Last updated: May 2026 | Language: C
Key Features
- Zero daemon overhead: Direct kernel configuration, no background service
- Full kernel bonding API: All 7 bonding modes supported
- Immediate effect: Changes apply instantly without service restarts
- Scriptable: Ideal for init scripts, PXE boot, and embedded systems
- Works everywhere: Available on all Linux distributions
Configuration
| |
Systemd Service (Persistent)
| |
| |
Comparison Table
| Feature | systemd networkd | NetworkManager | iproute2 |
|---|---|---|---|
| LACP (802.3ad) | Yes | Yes | Yes |
| Configuration Style | Declarative (INI files) | Declarative + CLI | Imperative (commands) |
| Dynamic Reconfiguration | Via file reload | Via nmcli | Manual re-execution |
| Link Monitoring | MII/ARP | MII/ARP | MII/ARP |
| LACP Rate Control | slow/fast | slow/fast | slow/fast |
| Hash Policies | All 6 modes | All 6 modes | All 6 modes |
| GUI Available | No | Yes (nm-connection-editor) | No |
| Desktop Integration | Limited | Full | None |
| Server Suitability | Excellent | Good | Excellent |
| Dependencies | systemd | NetworkManager | kernel + iproute2 |
| Best For | systemd servers | Desktop/mixed | Minimal/embedded |
Why Self-Host Your LACP Configuration?
Self-hosting LACP bond configuration on your servers ensures high availability and bandwidth aggregation without depending on cloud provider virtual networking abstractions. When you manage your own link aggregation, you control the failover behavior, load balancing algorithm, and LACP negotiation parameters — critical factors for storage networks, virtualization hosts, and database clusters where network reliability directly impacts service availability.
Running LACP bonds on your own hardware means you can optimize the transmit hash policy for your specific traffic patterns, configure LACP fast transmission rates for quicker failure detection, and integrate bond monitoring with your existing alerting infrastructure. Whether you prefer the declarative simplicity of systemd networkd, the flexibility of NetworkManager, or the bare-metal control of iproute2, self-hosting gives you the freedom to choose the approach that best fits your operational model.
For VLAN configuration on bonded interfaces, see our VXLAN tunneling guide covering Open vSwitch and OVN. If you need network interface diagnostics, our ethtool vs mii-tool comparison covers interface management tools. For GRE tunnel management, check our OVS vs Linux GRE vs GRETAP guide.
FAQ
What is the difference between LACP and static link aggregation?
LACP (802.3ad, mode 4) dynamically negotiates the bond with the connected switch using LACPDU packets, verifying that both ends agree on the aggregation. Static link aggregation (mode 0, balance-rr) configures the bond without negotiation — both sides must be manually configured to match. LACP is preferred because it detects misconfigurations, validates link state, and can automatically remove failed links from the aggregate.
Which LACP transmit hash policy should I use?
The layer3+4 policy (default) hashes based on source/destination IP addresses and TCP/UDP ports, providing good load distribution for most workloads. Use layer2+3 if you need consistent MAC-level hashing for bridged traffic. For IPv6-heavy environments, encap2+3 includes inner header hashing for tunneled traffic. Test with your actual traffic patterns — the optimal policy depends on your workload characteristics.
Can I use LACP with unmanaged switches?
No. LACP requires the connected switch to support and be configured for 802.3ad link aggregation. If your switch does not support LACP, you can use bonding mode active-backup (mode 1) for failover-only redundancy, which does not require switch configuration. Alternatively, use balance-tlb (mode 5) or balance-alb (mode 6) for adaptive load balancing without switch support.
How do I monitor LACP bond health?
Check /proc/net/bonding/bond0 for real-time bond status, including active slave interfaces, link state, and LACP partner information. With systemd networkd, use networkctl status bond0. With NetworkManager, use nmcli device status. For automated monitoring, track the bonding_mii_status or use SNMP to poll the ifOperStatus of bond member interfaces.
What is LACP fast transmission rate?
LACP fast mode sends LACPDU packets every 1 second (vs. 30 seconds in slow mode), enabling faster detection of link failures and misconfigurations. Configure lacp_rate=fast in your bond settings for environments where rapid failover is critical. The switch must also support fast LACP for this to work — both ends must agree on the transmission rate.
Does LACP increase per-connection throughput?
No. LACP load balances across member links using a hash algorithm, but a single TCP/UDP flow always uses one physical link. The aggregate bandwidth is shared across multiple independent flows. For a single large file transfer, you will see at most the speed of one member link. Multiple simultaneous transfers will distribute across the aggregate bandwidth.