3、链路聚合（LACP）：IEEE 802.3ad标准详解，Linux下bonding模式0-6配置实战

链路聚合，说白了就是把多条物理网卡绑成一条逻辑链路。我刚开始接触这个技术时，总觉得它就是个「网卡捆绑」的小把戏。直到有一次在边缘网关项目里，单条千兆链路被视频流撑爆了，我才真正意识到——这玩意儿是工业现场的网络救星。

IEEE 802.3ad标准，就是给这个「捆绑」定规矩的。它规定了怎么协商、怎么负载均衡、怎么容错。嗯，咱们今天就把这个标准掰开揉碎，再配上Linux bonding的实战配置。

3.1 IEEE 802.3ad标准核心

802.3ad标准的核心，其实就两件事：链路聚合控制协议（LACP）和帧分发策略。

LACP负责自动协商。两台设备之间通过交换LACPDU报文，确认哪些端口可以聚在一起。我见过不少工程师手动配置静态聚合，结果交换机一端换了端口，链路就断了。用LACP，这种问题基本不会发生。

帧分发策略决定了数据包走哪条物理链路。标准里定义了多种哈希算法，比如基于MAC地址、IP地址、TCP/UDP端口号。你想想看，如果哈希算法选得不好，所有流量都挤在一条链路上，那聚合还有什么意义？

关键参数：

  • 系统优先级：决定哪端设备主导协商，值越小优先级越高
  • 端口优先级：决定端口在聚合组里的地位
  • 操作Key：标识端口的能力（速率、双工模式等），只有Key相同的端口才能聚合
  • 聚合组ID：由系统MAC和系统优先级共同生成

我曾经在一个风电场的边缘节点上踩过坑。两台交换机之间做了LACP，但一端是百兆端口，另一端是千兆端口。结果LACP协商失败，链路直接不通。后来查了标准才知道——操作Key不一致，聚合组根本建不起来。

3.2 Linux bonding模式详解

Linux内核的bonding驱动支持7种模式，编号0到6。每种模式都有它的脾气。我个人的习惯是：先搞清楚业务场景，再选模式，而不是反过来。

模式 名称 特点 适用场景
0 balance-rr 轮询分发，按包顺序轮流走不同网卡 需要最大吞吐量的场景，但要求对端也支持
1 active-backup 主备模式，只有一块网卡工作 高可用场景，对端不需要特殊配置
2 balance-xor 基于哈希算法分发，同一连接走同一链路 需要负载均衡且避免乱序的场景
3 broadcast 所有包在所有网卡上广播 特殊冗余场景，极少用
4 802.3ad 遵循IEEE 802.3ad标准，使用LACP 工业现场、数据中心标准方案
5 balance-tlb 自适应发送负载均衡，接收端不均衡 发送流量远大于接收流量的场景
6 balance-alb 自适应负载均衡，收发都均衡 需要双向均衡且不想配交换机的场景

这里我要多说一句模式4。它是唯一一个完全遵循802.3ad标准的模式。说白了，如果你对端是支持LACP的交换机，那就用模式4。我在智能工厂的项目里，所有边缘网关和工业交换机之间都跑的模式4，稳得很。

3.3 实战：Linux bonding配置

配置bonding其实不复杂，但有几个坑。我直接上实战步骤，你跟着走一遍就明白了。

3.3.1 安装bonding模块

先确认内核有没有加载bonding模块：

# 检查模块是否加载
lsmod | grep bonding

# 如果没有，手动加载
modprobe bonding

# 设置开机自动加载
echo "bonding" >> /etc/modules

3.3.2 创建bond接口

我习惯用nmcli来配，但如果你用的是纯命令行环境，直接改配置文件也行。这里给两种方式：

方式一：使用nmcli（推荐）

# 创建bond接口，模式4（802.3ad）
nmcli connection add type bond con-name bond0 ifname bond0 mode 802.3ad

# 添加两个从接口
nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname eth1 master bond0
nmcli connection add type ethernet slave-type bond con-name bond0-port2 ifname eth2 master bond0

# 配置IP地址
nmcli connection modify bond0 ipv4.addresses 192.168.1.100/24
nmcli connection modify bond0 ipv4.method manual

# 启动
nmcli connection up bond0

方式二：手动配置文件

# /etc/network/interfaces (Debian/Ubuntu)
auto bond0
iface bond0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    bond-slaves eth1 eth2
    bond-mode 4
    bond-miimon 100
    bond-lacp-rate fast
    bond-xmit-hash-policy layer3+4

auto eth1
iface eth1 inet manual
    bond-master bond0

auto eth2
iface eth2 inet manual
    bond-master bond0

我的经验：bond-miimon设为100毫秒，这个值比较均衡。设得太小（比如10ms），链路抖动时会频繁切换；设得太大（比如1000ms），故障恢复太慢。100ms是我在多个项目里试出来的「甜点值」。

3.3.3 配置LACP参数

模式4下，LACP的参数直接影响协商效果：

# 查看当前LACP状态
cat /proc/net/bonding/bond0

# 设置LACP速率（fast=1秒，slow=30秒）
echo "fast" > /sys/class/net/bond0/bonding/lacp_rate

# 设置哈希策略
echo "layer3+4" > /sys/class/net/bond0/bonding/xmit_hash_policy

哈希策略我建议用layer3+4，它基于IP和端口做哈希，比默认的layer2均衡得多。我在一个视频监控项目里做过测试，layer2策略下两条链路利用率分别是80%和20%，换成layer3+4后变成了55%和45%。

3.4 避坑指南

我曾经踩过的坑：

  • 交换机配置不匹配：一端配了LACP，另一端配了静态聚合，结果链路时通时断。后来统一改成LACP才解决。
  • MTU不一致：bond接口的MTU必须和从接口一致。我遇到过eth1是1500，eth2是9000，结果大包全丢了。
  • 网卡驱动问题：有些老旧网卡不支持LACP的某些特性。建议用ethtool -i eth1先查一下驱动版本。
  • 链路数量：不是越多越好。我见过有人绑了8条千兆链路，结果哈希冲突严重，实际吞吐量还不如4条。一般2-4条就够了。

3.5 验证与监控

配置完了，怎么知道它跑得好不好？我一般用这几个命令：

# 查看bond状态
cat /proc/net/bonding/bond0

# 查看链路利用率
sar -n DEV 1 5

# 查看LACP协商状态（需要安装tcpdump）
tcpdump -i bond0 -e -vvv -c 10 ether proto 0x8809

重点关注/proc/net/bonding/bond0里的几个字段：

  • MII Status：up表示链路正常
  • Link Failure Count：链路故障次数，如果持续增长说明物理链路有问题
  • Active Slave：当前活跃的从接口
  • LACP active：是否成功协商

嗯，链路聚合这块内容就这些。说白了，802.3ad标准给了你一个可靠的框架，Linux bonding给了你灵活的实现。选对模式、配好参数、做好监控，边缘设备的网络冗余基本就稳了。

← 上一章 📖 返回目录 下一章 →