Hjälpcentral

This article provides directions to configure LACP on dedicated server operating systems. This article is applicable for clients of dedicated servers.

Overview

LACP (Link Aggregation Control Protocol) groups two or more physical network interfaces into one logical interface, such as bond0, lagg0, a Windows NIC team, or a vSphere Distributed Switch LAG. The server and switch must both be configured for 802.3ad/LACP. On Linux, 802.3ad is bonding mode 802.3ad or mode 4; it requires compatible switch support, and most switches require explicit LAG or port-channel configuration.

LACP improves aggregate throughput across multiple flows and provides link redundancy. It does not usually make one single TCP/UDP session faster than one physical link, because traffic is distributed using a hash algorithm.

Before You Start

Perform this work from an out-of-band console, KVM, IPMI, iDRAC, iLO, rescue console, or hypervisor console whenever possible. Network misconfiguration can disconnect the server.

Confirm the following before changing the operating system:

Use the following placeholder values in the examples:

How to Configure LACP on Dedicated Server Operating Systems

1. Ubuntu Server with Netplan

   Ubuntu Server commonly uses Netplan to define network configuration. In Netplan, link aggregation is configured as a bond interface under the bonds: mapping, while addresses are assigned to the bond rather than to the physical NICs.

   Procedure

   Identify the physical interfaces:

   ip -br link
   

   Back up the current Netplan configuration:

   sudo mkdir -p /root/netplan-backup
   sudo cp -a /etc/netplan/*.yaml /root/netplan-backup/
   

   Create or edit a Netplan file:

   sudo nano /etc/netplan/01-lacp-bond.yaml
   

   Example static IPv4 LACP configuration:

   network:
     version: 2
     renderer: networkd
   
     ethernets:
       eno1:
         dhcp4: false
         optional: true
       eno2:
         dhcp4: false
         optional: true
   
     bonds:
       bond0:
         interfaces:
           - eno1
           - eno2
         addresses:
           - 192.0.2.10/24
         routes:
           - to: default
             via: 192.0.2.1
         nameservers:
           addresses:
             - 192.0.2.53
         parameters:
           mode: 802.3ad
           lacp-rate: fast
           mii-monitor-interval: 100
           transmit-hash-policy: layer3+4
   

   Apply safely:

   sudo netplan generate
   sudo netplan try
   

   Confirm the configuration when prompted. netplan try is useful on remote systems because it can roll back if the configuration is not confirmed.

   After confirmation, apply permanently:

   sudo netplan apply
   

   Validate:

   ip addr show bond0
   cat /proc/net/bonding/bond0
   

   Expected indicators include:

   Bonding Mode: IEEE 802.3ad Dynamic link aggregation
   MII Status: up
   Slave Interface: eno1
   Slave Interface: eno2
   

   ---

2. Debian with /etc/network/interfaces

   Use this procedure when Debian networking is managed through /etc/network/interfaces, such as with ifupdown-ng or ifupdown2-style configurations. Debian’s bonding interface options include bond-members, bond-mode, bond-miimon, bond-lacp-rate, and bond-xmit-hash-policy; LACP-specific options apply when the bond mode is 802.3ad.

   Procedure

   Identify interfaces:

   ip -br link
   

   Back up the current interfaces file:

   sudo cp -a /etc/network/interfaces /root/interfaces.backup.$(date +%F-%H%M%S)
   

   Edit the network configuration:

   sudo nano /etc/network/interfaces
   

   Example configuration:

   auto lo
   iface lo inet loopback
   
   iface eno1 inet manual
   iface eno2 inet manual
   
   auto bond0
   iface bond0 inet static
       address 192.0.2.10/24
       gateway 192.0.2.1
       dns-nameservers 192.0.2.53
   
       bond-members eno1 eno2
       bond-mode 802.3ad
       bond-miimon 100
       bond-lacp-rate fast
       bond-xmit-hash-policy layer3+4
   

   Apply the configuration from console access. On systems with ifupdown2:

   sudo ifreload -a
   

   On systems without live reload support, schedule a maintenance window and restart networking or reboot.

   Validate:

   ip addr show bond0
   cat /proc/net/bonding/bond0
   

   ---

3. RHEL, Rocky Linux, AlmaLinux, and Oracle Linux with NetworkManager

   RHEL-compatible distributions commonly use NetworkManager. Red Hat documents nmcli as a command-line tool for creating, displaying, editing, deleting, activating, and deactivating NetworkManager connections.

   For LACP, use bonding mode 802.3ad. Red Hat’s documentation notes that switch-side mode must match the bonding mode, and mode 4/802.3ad requires an LACP-negotiated EtherChannel or equivalent switch configuration.

   Procedure

   Identify interfaces:

   nmcli device status
   

   Create the LACP bond:

   sudo nmcli connection add type bond \
     con-name bond0 \
     ifname bond0 \
     bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
   

   Add physical NICs as bond ports:

   sudo nmcli connection add type ethernet \
     con-name bond0-port1 \
     ifname enp7s0 \
     controller bond0 \
     port-type bond
   
   sudo nmcli connection add type ethernet \
     con-name bond0-port2 \
     ifname enp8s0 \
     controller bond0 \
     port-type bond
   

   Configure the IP address:

   sudo nmcli connection modify bond0 \
     ipv4.addresses 192.0.2.10/24 \
     ipv4.gateway 192.0.2.1 \
     ipv4.dns 192.0.2.53 \
     ipv4.method manual \
     ipv6.method disabled
   

   Enable automatic activation of the bond ports:

   sudo nmcli connection modify bond0 connection.autoconnect-ports 1
   

   Activate the bond:

   sudo nmcli connection up bond0
   

   Validate:

   nmcli connection show --active
   cat /proc/net/bonding/bond0
   

   For older RHEL or CentOS releases, the nmcli syntax may use master bond0 or slave-type bond instead of controller bond0 and port-type bond. Red Hat notes that the newer controller/port terminology applies to newer RHEL NetworkManager versions.

   ---

4. Proxmox VE

   Proxmox VE uses the Linux networking stack and stores network configuration in /etc/network/interfaces. Proxmox recommends managing network changes through the GUI when possible, and notes that systems using ifupdown2 can apply changes live without requiring a reboot.

   Proxmox supports Linux bonds and describes 802.3ad as LACP. It recommends LACP when the switch supports it; otherwise, active-backup is the safer fallback.

   Option A: Configure through the Proxmox GUI

   1. Log in to the Proxmox web interface.
   2. Select the node.
   3. Go to System > Network.
   4. Create a Linux Bond.
   5. Set:
   • Name: bond0
   • Slaves: eno1 eno2
   • Mode: 802.3ad
   • Hash policy: layer2+3 or the policy required by your switch design.
   1. Edit or create the Linux Bridge, usually vmbr0.
   2. Set bond0 as the bridge port.
   3. Apply the configuration.
   4. Confirm switch-side LACP is active.

   Option B: Configure /etc/network/interfaces

   Back up the file:

   cp -a /etc/network/interfaces /root/interfaces.backup.$(date +%F-%H%M%S)
   

   Edit the file:

   nano /etc/network/interfaces
   

   Example Proxmox bridge-over-LACP configuration:

   auto lo
   iface lo inet loopback
   
   iface eno1 inet manual
   iface eno2 inet manual
   
   auto bond0
   iface bond0 inet manual
       bond-slaves eno1 eno2
       bond-miimon 100
       bond-mode 802.3ad
       bond-xmit-hash-policy layer2+3
   
   auto vmbr0
   iface vmbr0 inet static
       address 192.0.2.10/24
       gateway 192.0.2.1
       bridge-ports bond0
       bridge-stp off
       bridge-fd 0
   

   Apply from the GUI or, when ifupdown2 is installed and supported:

   ifreload -a
   

   Validate:

   ip addr show vmbr0
   cat /proc/net/bonding/bond0
   

   ---

5. Windows Server NIC Teaming with LACP

   Windows Server includes NIC Teaming through the NetLbfo PowerShell module. Microsoft documents New-NetLbfoTeam for creating teams and supports specifying -TeamingMode LACP, -LoadBalancingAlgorithm, and -LacpTimer. The feature is available on Windows Server beginning with Windows Server 2012.

   Procedure with PowerShell

   Open PowerShell as Administrator.

   List adapters:

   Get-NetAdapter
   

   Create the LACP team:

   New-NetLbfoTeam `
     -Name "LACP-Team0" `
     -TeamMembers "Ethernet1","Ethernet2" `
     -TeamingMode LACP `
     -LoadBalancingAlgorithm Dynamic `
     -LacpTimer Slow
   

   Configure IPv4 on the team interface:

   New-NetIPAddress `
     -InterfaceAlias "LACP-Team0" `
     -IPAddress 192.0.2.10 `
     -PrefixLength 24 `
     -DefaultGateway 192.0.2.1
   

   Configure DNS:

   Set-DnsClientServerAddress `
     -InterfaceAlias "LACP-Team0" `
     -ServerAddresses 192.0.2.53
   

   Validate:

   Get-NetLbfoTeam
   Get-NetLbfoTeamMember -Team "LACP-Team0"
   Get-NetIPConfiguration -InterfaceAlias "LACP-Team0"
   

   Procedure with Server Manager

   1. Open Server Manager.
   2. Select Local Server.
   3. Click NIC Teaming.
   4. Create a new team.
   5. Select the physical NICs.
   6. Open Additional properties.
   7. Set Teaming mode to LACP.
   8. Select the appropriate load-balancing mode.
   9. Apply the team.
   10. Assign IP settings to the new team interface.

   For Hyper-V and software-defined networking deployments, Microsoft also documents Switch Embedded Teaming, or SET, as a separate option integrated with the Hyper-V Virtual Switch. Use the design required by the virtualization platform and vendor guidance.

   ---

6. FreeBSD with lagg(4)

   FreeBSD uses the lagg(4) interface for link aggregation. The FreeBSD Handbook describes LACP as the preferred link-aggregation protocol when the switch supports it, and notes that LACP negotiates links into one or more aggregated groups.

   Temporary Runtime Configuration

   Bring up the physical interfaces:

   ifconfig igb0 up
   ifconfig igb1 up
   

   Create the LACP interface:

   ifconfig lagg0 create
   ifconfig lagg0 up laggproto lacp laggport igb0 laggport igb1 192.0.2.10/24
   

   Add a default route if needed:

   route add default 192.0.2.1
   

   Validate:

   ifconfig lagg0
   

   Expected output should show laggproto lacp and member ports with LACP states such as ACTIVE, COLLECTING, and DISTRIBUTING.

   Persistent Configuration

   Edit /etc/rc.conf:

   vi /etc/rc.conf
   

   Add:

   ifconfig_igb0="up"
   ifconfig_igb1="up"
   cloned_interfaces="lagg0"
   ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 192.0.2.10/24"
   defaultrouter="192.0.2.1"
   

   Configure DNS if required:

   vi /etc/resolv.conf
   

   Example:

   nameserver 192.0.2.53
   

   Restart networking during a maintenance window or reboot.

   ---

7. VMware ESXi and vSphere

   VMware ESXi supports LACP only with a vSphere Distributed Switch, not with a standard vSwitch. Broadcom’s VMware documentation also recommends coordinating the physical switch and ESXi-side migration carefully, ideally by creating the LAG on the distributed switch first and moving uplinks gradually to avoid losing host connectivity.

   Requirements

   • vCenter-managed host.
   • vSphere Distributed Switch.
   • Physical switch ports configured for LACP.
   • Maintenance window or console access.
   • Matching VLAN, MTU, and load-balancing design.
   • Do not use LACP with unsupported scenarios such as standard vSwitch LACP, SR-IOV passthrough, or nested ESXi LACP configurations.

   Procedure

   1. Log in to the vSphere Client.
   2. Go to Networking.
   3. Select the vSphere Distributed Switch.
   4. Open Configure.
   5. Go to Settings > LACP.
   6. Click New.
   7. Configure:
      • Name: Example LAG01
      • Number of ports: Match the number of physical NICs, such as 2
      • Mode: Active or Passive; at least one side of the LACP negotiation must be active.
      • Load balancing mode: Match the physical switch design.
      • Timeout: Match the switch/vendor policy.

   8. Assign the LAG to the relevant distributed port groups.

   9. Move the LAG to the active uplink list and move individual uplinks to unused or standby according to the migration plan.

   10. Migrate one physical NIC at a time:

       • Move the physical switch port into the LACP port-channel.
       • Assign the corresponding vmnic to the distributed switch LAG.
       • Verify host connectivity.
       • Repeat for the next NIC.

   11. Verify LACP status in vSphere and on the physical switch.

   Broadcom’s procedure describes creating the LAG, connecting physical adapters, configuring teaming/failover order, and then migrating uplinks and traffic to the LAG.

Validation Checklist

After configuration, confirm both the server and switch show the bundle as active.

Linux

cat /proc/net/bonding/bond0
ip -br addr show bond0
ip route

Look for:

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
Slave Interface: 
Slave Interface: 
Aggregator ID: 

Linux exposes bonding status and options through /proc/net/bonding/bondX, which is the primary place to inspect slave state, active aggregator details, and link status.

Windows Server

Get-NetLbfoTeam
Get-NetLbfoTeamMember -Team "LACP-Team0"
Get-NetIPConfiguration -InterfaceAlias "LACP-Team0"

FreeBSD

ifconfig lagg0
netstat -rn

ESXi

Check:

• vSphere Distributed Switch LACP status.
• Host uplink assignment.
• Distributed port group teaming and failover order.
• Physical switch LACP neighbor or port-channel status.

Physical switch

Use the vendor equivalent of:

show lacp neighbor
show port-channel summary
show etherchannel summary
show interfaces lag
show interfaces ae

Exact commands depend on the switch vendor.

Failure Testing

Test during a maintenance window.

1. Start a continuous ping from another host to the server.
2. Disconnect or administratively disable one member link.
3. Confirm traffic continues.
4. Re-enable the link.
5. Repeat for the other member link.

Red Hat notes that physically unplugging a cable is the proper way to test link failure behavior, because software-only tests may not accurately simulate real link loss.

Common Problems and Fixes

Rollback Procedures

Ubuntu / Netplan

Restore the backup:

sudo cp -a /root/netplan-backup/*.yaml /etc/netplan/
sudo netplan apply

Debian / Proxmox

Restore the previous /etc/network/interfaces file:

sudo cp -a /root/interfaces.backup.YYYY-MM-DD-HHMMSS /etc/network/interfaces
sudo ifreload -a

If live reload is not available, reboot during a maintenance window.

RHEL-Compatible Linux

Deactivate and delete the bond profiles:

sudo nmcli connection down bond0
sudo nmcli connection delete bond0 bond0-port1 bond0-port2

Reactivate the previous NIC profile:

sudo nmcli connection up ""

Windows Server

Remove the team:

Remove-NetLbfoTeam -Name "LACP-Team0" -Confirm:$false

Reassign IP settings to the original physical adapter if needed.

FreeBSD

Destroy the runtime lagg interface:

ifconfig lagg0 destroy

Restore the previous /etc/rc.conf configuration and restart networking or reboot.

ESXi

1. Move one physical switch port out of the LACP bundle.
2. Move the matching vmnic back to a normal uplink path.
3. Restore distributed port group teaming order.
4. Confirm management connectivity.
5. Remove the LAG after all traffic is migrated away.

Completion Criteria

The configuration is complete when:

• The server-side bond/team/LAG is up.
• The switch-side LACP group shows all intended links bundled.
• The server IP is assigned only to the logical interface.
• Default gateway and DNS resolution work.
• Each member link can fail without disconnecting the server.
• Application traffic passes normally across the aggregated interface.

Conclusion

You now know how to configure LACP for dedicated server operating systems.

Related:

• Deploy Dedicated Servers
• Bind Additional IPs to NIC - RHEL-based Systems
• Creating Network Bridge for KVM Hypervisor
• Choosing an Operating System