Linux 的 bonding 驱动允许把多块物理网卡聚合成一个名为 bond0 的逻辑接口。这个逻辑接口对上呈现统一的 IP 和 MAC 地址，对下根据绑定模式在多块物理网卡之间分发流量或执行故障切换。要实现高可用与负载均衡，不能只是把两块网卡绑在一起就结束，关键要理解内核 bonding 的工作模式、链路检测机制以及交换机侧是否需要配合。
bond0 的绑定模式决定了高可用和负载均衡的边界
bonding 驱动支持七种工作模式，从 mode=0 到 mode=6。mode=0 是轮询模式，所有数据包依次从各个从属网卡发出，能够提升总带宽，但可能造成 TCP 报文乱序，而且交换机不参与协商，容易诱发 MAC 地址漂移。mode=1 是主备模式，只有一块网卡处于活动状态，另一块作为备份，故障时自动切换，但它只提供高可用，无法叠加带宽。mode=4 是 IEEE 802.3ad 动态链路聚合，依赖 LACP 协议与交换机协同工作，既能实现冗余切换，也能在多流场景下负载均衡。mode=6 是适配器自均衡模式，不需要交换机支持，但通过修改 ARP 应答分配流量，复杂网络中容易出问题。
如果不理解模式差异，很容易把 mode=0 或 mode=1 误认为同时具备高可用和负载均衡。生产环境通常优先选择 mode=4，因为它在可靠性和带宽利用上最为平衡。mode=0 在交换机没有加入聚合组时，报文的源 MAC 会在多个物理端口之间跳跃，交换机端口安全功能可能直接阻断网络。mode=1 的备份链路完全空闲，投入两块网卡却只获得一块的性能，对成本敏感的场景并不划算。
可以先用 modinfo 查看当前内核支持的模式说明：
# 查看 bonding 驱动支持的模式说明 modinfo bonding | grep -E 'parm:.*mode' # 输出示例 # parm: mode:Mode of operation: 0 for round-robin, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb (int)
配置 bond0 的关键步骤与参数说明
在生产环境中配置 bond0，通常会先停用 NetworkManager 或者通过 nmcli 管理，因为 NetworkManager 对网络脚本的覆盖可能导致绑定的从属关系丢失。在 RHEL/CentOS 7 及更早版本中，最稳妥的方式是直接在 /etc/sysconfig/network-scripts/ 下创建 ifcfg-bond0 和从属网卡配置文件。
下面是 bond0 主配置文件示例，假设服务器使用 192.168.10.0/24 网段，绑定模式为 802.3ad，链路检测周期 100ms，哈希策略选择 layer2+3：
# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none ONBOOT=yes IPADDR=192.168.10.50 PREFIX=24 GATEWAY=192.168.10.1 BONDING_OPTS="mode=4 miimon=100 xmit_hash_policy=layer2+3 lacp_rate=1"
对应物理网卡 eth0 和 eth1 需要删除原有 IP 配置，并将它们标记为 bond0 的从属设备：
# /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none NAME=eth0 DEVICE=eth0 ONBOOT=yes MASTER=bond0 SLAVE=yes
miimon 是 MII 链路状态检测参数，单位毫秒，miimon=100 表示内核每 100ms 检查一次网卡链路。arp_interval 可以作为替代检测手段，通过定期发送 ARP 请求判断链路是否可用，但两者不能同时配置，否则内核会拒绝加载绑定参数。xmit_hash_policy 用于决定流量如何分摊到不同 slave，常见取值有 layer2、layer3、layer2+3 和 layer3+4。对于 TCP/UDP 流，layer3+4 可以把不同会话分散得更均匀，但会消耗更多 CPU；layer2+3 在多数交换机聚合场景下兼容性更好。lacp_rate=1 表示快速 LACP 协商，交换机侧需要同步配置为 fast。
交换机侧配合与验证
如果选择 mode=4，交换机端必须配置动态链路聚合，也就是 IEEE 802.3ad 标准下的 LACP。不同厂商命名不一样：思科叫 Port-channel，华为和华三叫 Eth-Trunk，但它们协商机制是一致的。交换机需要把连接服务器的两个端口加入同一个聚合组，并开启 LACP 动态协商；若交换机只配置了静态聚合而服务器端是动态 LACP，双方握手会失败。
mode=0 和 mode=6 通常不需要交换机特别配置，但 mode=0 在交换机端口上可能出现 MAC 地址漂移告警，甚至会触发端口安全策略导致断网。mode=6 balance-alb 虽然不需要交换机支持，但会通过修改 ARP 应答来让不同客户端走不同网卡，在复杂网络环境中可能引发 ARP 缓存异常。因此生产环境优先考虑 mode=4。
配置完成后，查看 /proc/net/bonding/bond0 可以确认 LACP 协商状态、聚合组 ID 和活跃从属设备。重点关注输出中的 Aggregator ID 和 MII Status：
cat /proc/net/bonding/bond0 # 关键字段 # Bonding Mode: IEEE 802.3ad Dynamic link aggregation # MII Status: up # 802.3ad info # LACP active: on # Aggregator ID: 1 # Slave Interface: eth0 # MII Status: up # Slave Interface: eth1 # MII Status: up
如果 Aggregator ID 显示为 0 或者某个 slave 的 MII Status 为 down，需要回头检查交换机 LACP 配置、网线连接以及从属网卡是否被正确识别。
故障切换与负载均衡的实测方法
高可用测试可以借助持续 ping 网关来观察故障切换时间。在 bond0 上运行无限 ping，然后拔掉主用网卡网线，理想情况下流量会切换到另一块网卡，ping 只出现一两个丢包。miimon=100 的检测周期决定了故障发现时间通常在 200ms 到 300ms 左右，网络拓扑较复杂时可能稍长。
负载均衡测试需要制造多个并发流，因为 bond0 的哈希策略针对流而不是包。单个 TCP 连接只会走其中一块网卡，无法超过单链路的物理带宽。可以用 iperf3 同时开多线程，或者从多个不同客户端向服务器发起并发连接，再通过 /proc/net/dev 观察两块物理网卡的流量和计数是否接近。
# 终端一持续 ping ping -f 192.168.10.1 & # 终端二观察 slave 切换 watch -n 1 'cat /proc/net/bonding/bond0 | grep -A4 "Slave Interface"' # 查看 slave 累计流量 grep -E 'eth0|eth1' /proc/net/dev
如果发现所有流量始终集中在同一块网卡，先确认上层交换机是否支持 LACP 且聚合组协商成功，再检查 xmit_hash_policy 是否设置过粗。只按 MAC 地址做哈希时，当服务器只和一个默认网关通信，源和目标 MAC 都固定，流量必然全部落在同一个 slave 上。
常见问题与注意事项
在配置和运行 bond0 时，最容易出现的问题包括从属网卡 MAC 地址漂移、NetworkManager 覆盖手工配置、MTU 不一致以及 hash 策略选择不当。从属网卡的 MAC 地址通常由 bonding 驱动统一管理，用户不应在从属网卡配置里手工指定 MACADDR；如果指定错误，可能导致 LACP 协商不稳定。
另一个高频故障是 MTU 不匹配。服务器 bond0 设置了 jumbo frame，而交换机或对端设备 MTU 仍为 1500，大包会被丢弃，表现为小数据包正常、大数据传输卡顿。建议整条链路统一 MTU，并在交换机上确认允许通过。
使用 NetworkManager 的环境建议用 nmcli 管理 bond0，或者直接关闭并禁用 NetworkManager，否则重启后可能出现 bond0 消失、slave 关系丢失的问题。此外，配置修改完成后不要只重启单个网卡，最好重启整个网络服务或直接重启系统，确保从属关系按正确顺序加载。生产环境变更前应保留原始网卡配置备份，便于快速回退。
Linux bond0网络高可用负载均衡修改时间：2026-09-29 15:20:56