Linux LACP 链路聚合：配置、验证与故障排除

Linux LACP 链路聚合将多个以太网接口组合成单一逻辑链路，为您提供更高的聚合带宽，并在物理网卡之间实现自动故障转移。它采用 IEEE 802.3ad 标准，由双方（服务器和交换机）协商确定哪些链路处于活动状态以及流量如何分配。 本文将介绍 LACP 的实际作用、何时应优先选择它而非其他 Linux 绑定模式、如何在现代 Linux 服务器上进行配置，以及如何验证其运行状态。

什么是链路聚合和 LACP？

链路聚合将多个物理网络连接组合成一个逻辑通道。它有两个目的：增加链路组中的总可用带宽，并在任何单个成员链路发生故障时提供自动故障转移。

LACP（链路聚合控制协议）是 IEEE 802.3ad 定义的链路聚合动态版本。LACP 不再依赖两端的静态配置，而是通过服务器与交换机之间交换名为 LACPDU 的控制数据包来实现。 双方通过协商确定哪些链路加入聚合组，监控每条链路的状态，并根据情况变化将成员链路加入或移出组。

在 Linux 环境中，LACP 作为内核 bonding 驱动程序的模式 4（802.3ad）运行。该驱动程序会创建一个逻辑接口（通常 bond0) 来持有 IP 地址，而物理接口如 eth0 和 eth1 等物理接口则成为该绑定组的从属接口。从操作系统角度看，仅存在一个网络接口；从物理链路角度看，则存在多条并行的以太网链路。

LACP 明确不具备以下功能，尽管人们常对此抱有期待：

• 单个 TCP 连接仍仅通过一条物理链路传输。LACP 平衡的是流量，而非单个流量内的数据包。两条绑定在一起的 1 GbE 链路并不会使单次下载速度超过 1 Gbps。
• LACP 需要支持 802.3ad 的交换机。它无法与未管理型或不支持 LACP 的交换机建立链路聚合。
• 所有成员链路必须以相同的速度和双工模式运行。无法将 1 GbE 端口与 10 GbE 端口进行绑定。

Linux 绑定模式：何时使用 LACP

Linux 绑定驱动程序支持七种模式。大多数生产环境部署中通常使用其中三种。

模式 1：主动-备用

其中一个成员接口处于活动状态，其余处于空闲状态。若活动接口发生故障，另一个接口将在几百毫秒内接管。无需交换机配置，因此当交换机不在您的控制范围内或不支持 802.3ad 时，这是最佳选择。您将获得冗余，但不会获得额外带宽。

模式 4：802.3ad (LACP)

所有成员接口均承载流量。绑定驱动程序与交换机通过 LACP 协商活动集并检测故障。出站流量将根据您配置的哈希策略在成员接口间进行负载均衡。当您希望为多流工作负载同时获得冗余和额外带宽时，这是连接到受管交换机的专用服务器的标准选择。

模式 6：balance-alb

双向自适应负载均衡，无需交换机支持。驱动程序会拦截 ARP 响应以重写 MAC 地址并分发入站流量。该模式虽可正常工作，但与 LACP 相比稳定性较差。仅在确实无法配置交换机端时才应使用。

决策规则：

• 无管理型交换机，或仅需故障转移：模式 1（主动-备用）。
• 使用管理型交换机，且存在多路流，需要带宽和冗余：模式 4（LACP）。
• 无法使用管理型交换机但需要双向负载均衡：模式 6（balance-alb）。

模式 0（平衡-RR）、2（平衡-XOR）、3（广播）和 5（平衡-TLB）虽然存在，但在现代硬件上很少是合适的选择。除非有特殊原因，否则请选择模式 1 或模式 4。

在 Linux 上配置 LACP 链路聚合

在现代 Ubuntu 和 Debian 系统上，LACP 通过 netplan 进行配置。在 RHEL、CentOS Stream、AlmaLinux 和 Rocky Linux 上，请通过 nmcli 或直接编辑底层连接配置文件。

Netplan（Ubuntu、Debian）

将以下内容放入 /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

然后使用 netplan apply。关键参数：

• mode: 802.3ad 启用 LACP。
• lacp-rate: fast 每秒发送一次 LACPDU，而非默认的 30 秒。必须与交换机设置匹配。
• mii-monitor-interval: 100 每 100 毫秒轮询一次链路状态。
• transmit-hash-policy: layer3+4 根据源/目标 IP 地址和 TCP/UDP 端口分配流量。这比默认策略能产生更好的负载均衡效果 layer2 策略能为典型的 Web 和数据库流量提供更好的负载均衡。

NetworkManager (RHEL、AlmaLinux、Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

交换机端

交换机需要一个配置为 LACP 活动模式的 LAG 组（通常称为端口通道），其成员端口数量应与 bond 相同。 具体语法因厂商而异，但要求是相同的：端口必须位于同一 VLAN 中，设置为相同的速度和双工模式，并且至少在一侧使用 LACP 主动模式。双方均处于主动模式是最安全的设置。

在 Cisco IOS 上：

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

在 Aruba/ProCurve 上：

trunk 1-2 trk1 lacp

交换机上的 lacp_rate 交换机上的设置必须与主机一致。此处设置不一致是 LACP 配置中最常见的错误之一，会导致每 30 秒发生间歇性连接波动。

LACP 的验证与故障排除

在 Linux 端检查链路聚合的实时状态：

cat /proc/net/bonding/bond0

输出结果中需关注以下四点：

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation 确认模式 4 已加载。
2. 每个从属接口均以 MII Status: up 和 link failure count: 0.
3. 非零 Partner Mac Address 。此处全为零表示交换机完全未发送 LACP 数据包，原因可能是端口未处于 LACP 活跃的 LAG 中，或者电缆插错了端口。
4. Aggregator ID 在每个成员上都相同。ID不同意味着成员实际上并未组合，而是独立运作。

验证带宽是否被使用的最快方法是运行 iperf3 并使用多个并行数据流（iperf3 -P 8) 运行 iperf3。如果总吞吐量超过单条链路的带宽，则说明 LACP 正在正确地进行负载均衡。单流测试显示单条链路的速度是预期行为，并非故障。

最常见的 LACP 问题及其原因：

• 伙伴 MAC 地址全为零：交换机端口未加入 LACP 活跃的 LAG，或线缆接错。
• 链路聚合已建立但吞吐量仅限于单条链路：哈希策略可能默认设置为 layer2，该策略仅对目标 MAC 地址进行哈希。请切换至 layer3+4.
• 每 30 秒间歇性闪烁： lacp_rate 主机与交换机配置不匹配。
• 一个从属端口工作正常，但另一个从不承载流量：速率/双工模式不匹配，或者交换机端口在交换机端未处于同一个 LAG 组中。

当 LACP 并非最佳解决方案时

LACP 解决了一个特定问题：聚合单个主机与单个交换机（或单个交换机堆栈）之间的多条链路，以实现冗余和按流分配带宽。但在某些场景下，它并非最佳选择。

如果您仅需冗余，且交换机不支持 802.3ad，请改用模式 1（主动-备用）。该模式适用于任何设备。

若需跨两个独立交换机进行机箱级冗余，标准 LACP 无法连接两个互不关联的交换机。 此时需要使用多机箱链路聚合（MLAG），该技术可使两台交换机作为单一逻辑 LACP 伙伴呈现。大多数企业级交换机厂商均以自有品牌实现此功能：思科 vPC、Arista MLAG、瞻博 MC-LAG。

若需单个数据流的带宽超过单条链路的带宽，LACP无法实现。解决方案包括使用更高速的物理链路（例如用1条25 GbE或40 GbE链路替换2条10 GbE链路），或者完全采用其他技术。 SR-IOV 通过为每台虚拟机提供一个硬件加速的虚拟网卡，为虚拟机提供接近线速的单流性能，但它解决的是另一个问题，且存在自身的限制。这将是另一篇文章的主题。

对于处理大量并发连接的大多数专用服务器和托管服务器而言，LACP 仍是标准解决方案。两条绑定在一起的 10 GbE 链路配合 layer3+4 哈希算法，可轻松处理跨多个流的 18+ Gbps 聚合流量，同时在网卡或电缆故障时仍能保持零丢包。