Linux 网卡 Bonding 技术是保障服务器网络高可用性与提升吞吐量的核心手段，通过将多块物理网卡虚拟为一块逻辑网卡，它不仅实现了网络链路的冗余备份，还能在特定模式下聚合带宽，有效解决单点故障和网络瓶颈问题，在企业级生产环境中，合理配置 Bond 能够确保业务连续性，并在不升级硬件设备的前提下成倍提升网络性能。
核心工作模式深度解析
Linux Bonding 驱动提供了多种工作模式（Mode 0-6），不同的模式对应不同的应用场景和交换机配置要求。掌握这些模式的区别是实施网络优化的前提。
Mode 0 (balance-rr) 轮询策略：数据包按顺序依次从每一个网卡发出，该模式提供了负载均衡和容错能力，但要求交换机必须配置聚合端口，否则容易引发数据包乱序问题，导致 TCP 连接性能下降。
Mode 1 (active-backup) 主备策略：这是最常用的高可用模式，只有一块网卡处于活动状态，其余处于备份状态，当活动网卡故障时，备份网卡会立即接管。该模式的优势在于无需交换机做特殊配置，兼容性极强，适用于对带宽要求不高但对稳定性要求极高的场景。
Mode 4 (802.3ad) 动态链路聚合：这是企业级应用的首选模式，它基于 802.3ad 协议，通过创建聚合组来共享相同的速率和双工设置。该模式能提供真正的负载均衡和冗余，但要求交换机必须支持并开启 LACP（链路聚合控制协议），在此模式下，流量通常根据哈希算法（如基于源/目的 IP、端口）分发，确保同一连接的数据包在同一链路上传输，避免乱序。
Mode 6 (balance-alb) 适应性负载均衡：该模式在 Mode 1 的基础上增加了负载均衡功能，不需要交换机配置支持，它通过 ARP 协商实现负载均衡，适用于接收和发送流量都需要均衡的场景，但在处理复杂的大流量并发时，其性能略逊于 Mode 4。
企业级配置实战方案
在 CentOS/RHEL 8/9 或 Ubuntu 等现代 Linux 发行版中，推荐使用 nmcli（NetworkManager Command Line Interface）进行配置，相较于传统的修改 ifcfg 文件，这种方式更易于管理且不易出错。
以下是基于 Mode 4 (LACP) 的配置示例，假设物理网卡为 eth0 和 eth1，逻辑网卡名称为 bond0。
创建 Bond 接口并指定模式为 802.3ad：
nmcli con add type bond ifname bond0 mode 802.3ad
为 Bond 接口配置 IP 地址（以静态 IP 为例）：
nmcli con modify bond-bond0 ipv4.addresses 192.168.1.100/24 ipv4.method manual
将物理网卡添加为 Bond 的从属设备：
nmcli con add type ethernet slave-type bond con-name bond0-eth0 ifname eth0 master bond0 nmcli con add type ethernet slave-type bond con-name bond0-eth1 ifname eth1 master bond0
启动连接并验证状态：
nmcli con up bond-bond0 cat /proc/net/bonding/bond0
在 /proc/net/bonding/bond0 的输出中，必须确认 “MII Status” 为 up，且 “LACP rate” 已协商成功，这表明 Bond 接口已正常工作，且与交换机的 LACP 协握手成功。
交换机协同与网络环境关键点
配置服务器端 Bond 只是成功的一半，交换机的配置同样至关重要，尤其是在使用 Mode 0、2、3、4 时。
对于 Mode 4 (802.3ad)，交换机端口必须配置为 Trunk 模式，并加入同一个 Link Aggregation Group (LAG) 或 EtherChannel。务必确保交换机端的 LACP 模式设置为 “Active” 而非 “Passive”，以加快链路收敛速度，如果交换机配置不匹配，服务器端可能会出现网络抖动或完全不通。
所有物理网卡的速度和双工模式必须一致。eth0 是千兆网卡，eth1 是万兆网卡，Bonding 驱动通常会拒绝聚合，或者性能会受限于最慢的那块网卡，建议在 BIOS 或驱动层面强制指定网卡速率，避免自协商带来的不稳定因素。
性能调优与故障排查专业建议
在配置完成后,为了获得最佳性能，还需要关注以下专业细节：
- MTU 设置：如果网络环境支持巨型帧，建议将 Bond 接口的 MTU 值设置为 9000，这能显著降低 CPU 中断率，提升大数据包传输效率。注意：物理网卡和交换机端口的 MTU 必须同步调整，否则会导致丢包。
- 哈希策略调整：默认的
xmit_hash_policy（层2+层3）通常适用于大多数场景，但在某些特定的负载均衡器或 NFS 存储场景下，可能需要调整为layer3+4，以获得更均匀的流量分发。 - ARP 监控：对于 Mode 1 和 Mode 6，建议配置
arp_interval和arp_ip_target，通过定期发送 ARP 探测包，系统可以更快速地检测到上游链路故障（如交换机上行口断开），而不仅仅是检测到网卡链路断开。
在故障排查时,如果发现 Bond 接口不通，首先检查 /proc/net/bonding/bond0 中的 “Slave Interface” 状态，如果显示 “Link Failure”，请检查物理网线；如果显示 “Down”，请检查交换机配置。使用 ethtool -S bond0 可以查看详细的统计信息，通过对比各个 slave 端口的 rx_packets 和 tx_packets，可以直观地判断负载均衡是否生效。
相关问答
Q1：Linux Bonding 和 Bridge（网桥）有什么区别，能否同时使用？
A： Bonding 和 Bridge 解决的是不同层面的问题，Bonding 侧重于物理链路的聚合和冗余，工作在 OSI 模型的数据链路层和物理层之间；而 Bridge（如 Linux Bridge 或 Open vSwitch）侧重于模拟交换机功能，实现虚拟机或容器之间的二层转发。两者完全可以且经常同时使用，典型的架构是：物理网卡组成 Bond0，然后将 Bond0 桥接到 Virbr0 或其他网桥接口上，供虚拟机使用，这样既保证了物理链路的高可用，又实现了虚拟网络的互通。
Q2：在 Mode 4 模式下，为什么实际带宽没有达到网卡带宽的总和？
A： 这是由于流量哈希算法的限制，Bonding 基于数据包的头部信息（如 IP 地址、端口号）计算哈希值，将特定的流量“固定”在某一条物理链路上。单个 TCP 连接或 UDP 流只能使用其中一块物理网卡的带宽，只有当存在多个并发连接，且源/目的 IP 或端口分布足够离散时，总流量才会分散到多张网卡上，从而接近总带宽，Mode 4 提升的是“总吞吐量”而非“单连接带宽”。
希望这篇关于 Linux 网卡 Bond 的深度解析能帮助你在实际运维中构建更稳固的网络环境，如果你在配置过程中遇到特殊的兼容性问题，欢迎在评论区分享你的硬件型号和报错信息，我们一起探讨解决方案。
