企业官网建设流程全解析

按理说，把两块网卡绑在一起，带宽翻倍，链路冗余，是件挺简单的事。但我第一次给生产服务器配置 Linux 网卡 bond 模式时就翻过车：双千兆 bond 选成了 mode=0（balance-rr），割接后小流量一切正常，一到晚高峰，业务侧疯狂反馈丢包、卡顿。抓包一看，同一个 TCP 连接的数据包被打散到两条物理链路上，到对端后乱序、重传，把原本好好的链路给“忙”坏了。后来我把 7 种 bond 模式逐一研究并实测了一遍，才意识到每个模式背后的约束条件、适用的交换机配置、该配的检测参数，都不是默认值能替代的。这篇文章就把 7 种模式的原理、配置、选型逻辑和踩坑经验一次说清楚，适合 Linux 运维、网络工程师、虚拟化管理员参考。

1. 为什么服务器要把多块网卡“绑”成一张 bond 接口

1.1 单块网卡撑不住时，通常有两条路

服务器缺带宽时，最简单的方案是换一块更高速率的网卡：千兆不够上万兆，单万兆不够上 40G。但更换网卡往往伴随着服务器停机、驱动兼容、预算审批等一堆事情，而且一旦网卡坏了，整个网络入口就完全断掉。另一个思路是加网卡、不换带宽等级：服务器本来就有多个 PCIe 插槽，插两块甚至四块网卡的成本比换高速网卡低得多，这时就需要一种机制，让系统把多块物理网卡当成一块逻辑网卡来用。Linux 内核里的 bonding 模块干的就是这件事，它创建出来的虚拟接口叫 bond0，通过配置不同的 mode，决定数据包在成员网卡之间怎么走。

很多人会问：我直接给两块网卡配两个 IP，不也能同时用吗？能同时用，但应用层看到的就不是一个统一的网络入口了。比如连接数据库的连接串只能写一个 IP，断网卡时不会自动切到另一个 IP；再比如路由表里可能同时出现两条默认路由，出口行为变得不可控。bond 的核心价值在于向上层提供一个稳定的逻辑接口，对外只有一个 IP、一个 MAC 地址，物理层怎么切换、怎么负载均衡，上层应用完全不用关心。你可以把它理解成一支车队：单辆车容量不够，就多派几辆车，但调度中心必须统一编号、统一指派路线，否则货容易送错。bond 就是那个调度中心。

1.2 bond 解决的三个核心问题：带宽、冗余、负载均衡

bond 接口要解决的事情归纳起来是三个：带宽叠加、链路冗余、负载均衡。带宽叠加指多条物理链路同时转发，让总吞吐超过单块网卡的上限；链路冗余指某块网卡或某根网线故障时，其余成员网卡自动接管，业务不中断；负载均衡则是让流量相对均匀地分散到各成员网卡上，避免一块网卡被打满、其他网卡闲着。

但这里有个非常容易误解的点：不是所有模式都能同时做到这三件事。7 种模式的差异，本质上是“在什么层面做负载均衡”“是否需要交换机配合”“是否允许短时间内乱序”这几个问题上的取舍。有些模式看起来能叠加带宽，但对交换机有硬性要求；有些模式只能做冗余，带宽完全不加；有些模式对某些驱动和虚拟化环境兼容性很差。所以选模式不是拍脑袋挑一个数字，而是先想清楚你的业务最缺什么。下面的第 2 节就把 7 种模式逐个拆开讲。

2. 7种bond模式的原理、限制和适用场景逐一说透

2.0 总览：这些模式在“是否依赖交换机”上有根本分歧

在讲每个模式之前，先放一张总览表，方便后面读细节时对照。这张表里最重要的两列是“带宽叠加能力”和“交换机要求”，因为绝大多数线上事故都是这两列没对齐导致的。

后面每个模式我都会按“工作原理、优点、缺点、适用场景”四条线展开，但不会写成一模一样的模板，因为有些模式的坑特别值得单独多说几句。

2.1 mode=0 balance-rr：最直观，但别急着用

balance-rr 是 Round Robin 轮询，第一个包走 eth0，第二个包走 eth1，第三个包再走 eth0，以此类推，实现最彻底的负载均衡。从理想效果看，四块千兆网卡绑成 mode=0，总带宽看起来是 4Gbps，理论转发能力确实可以叠加。但问题也出在“彻底”这两个字上：同一个 TCP 连接的数据包会被分散到两条甚至更多物理链路上，经过交换机不同的端口后到达对端，时延和路径不完全一致，接收端看到的报文顺序是乱的。TCP 协议对乱序非常敏感，一旦乱序就触发重复确认和重传，严重时实际吞吐比单块网卡还差。

我在开头说的那次事故，就是 mode=0 在双千兆下的典型表现：小流量时乱序概率低，问题不明显；晚高峰流量一上来，TCP 重传率直接飙到 20%，业务卡成狗。此外，mode=0 还要求交换机把多个端口配置成静态链路聚合（比如 Cisco 的 on 模式、华为的手工链路聚合），否则交换机上同一 MAC 地址会反复从一个端口漂移到另一个端口，二层转发表不断抖动。除非你明确知道自己要的是“逐包负载均衡”，并且对乱序不敏感，否则普通业务不要选 0。

2.2 mode=1 active-backup：简单可靠的“主备”方案

active-backup 是很多人最熟悉的一种 bond：同一时刻只有一块网卡在工作，其他网卡处于备份状态。一旦 active 网卡的链路断开，系统从备份网卡里挑一块接替，切换时会把 bond 接口的 MAC 地址切到新网卡上，对外 IP 和 MAC 不变。因为同一时间只有一条链路在转发，所以不存在乱序，也不需要交换机做任何链路聚合配置，两个口可以分别接到两台交换机上，一旦某台交换机整机故障，另一条链路还能继续工作。

它的最大缺点是不增加带宽，两块千兆绑成 mode=1，总带宽还是千兆。但这恰恰是它的优点：结构简单、行为可预期、故障域最小。很多对带宽要求不高、但对连续性要求极高的场景，比如数据库心跳、管理网络、keepalived 节点之间的同步链路，选 mode=1 比选任何花哨的聚合模式都稳。配置时还可以通过 primary 参数指定主用网卡，正常情况下流量固定走 eth0，eth0 故障切到 eth1，恢复后会自动切回。

2.3 mode=2 balance-xor：静态聚合里的“均衡器”

balance-xor 的原理是按哈希值选择出口，默认的 xmit_hash_policy 是 layer2，也就是拿源 MAC 和目的 MAC 做异或，再按低位选择网卡。和 mode=0 的逐包轮询不一样，mode=2 对同一个通信对端来说，哈希结果是固定的：A 主机到 B 主机的所有流量都会走同一条链路，不会乱序。这一点让它比 balance-rr 靠谱得多，尤其是在大量客户端访问少数服务器、且流量相对分散的内网环境里，它能比较均匀地把不同主机的流量分摊到不同网卡上。

但 mode=2 有几个前提。一是交换机上要把这些端口配置成静态链路聚合，不然二层 MAC 表会抖动；二是哈希算法的均匀程度依赖流量模型，如果全网只有一台客户端在猛灌流量，那所有数据都哈希到同一块网卡，其他网卡闲着。另一个坑是默认 layer2 哈希只认 MAC，如果所有流量经过三层路由后源 MAC 都是网关的 MAC，那么到不同目标 IP 的流量可能还是被分到同一条链路。遇到这种情况，可以把 xmit_hash_policy 改成 layer2+3 或 layer3+4，让 IP 甚至端口参与哈希，但交换机侧的负载均衡 Hash 也要对应调整。

2.4 mode=3 broadcast：特殊场景才考虑的广播模式

broadcast 模式的机制非常“暴力”：每个报文从所有成员网卡各发一份，接收端会收到重复帧，代价是带宽完全不可能叠加，链路容量直接打对折甚至更低，但换来的是极高的容错性：只要还有一块网卡活着，报文就还能发出去，因为每块网卡都发送了完整副本。这种模式需要交换机把多个端口配置成静态聚合，否则重复帧和同一 MAC 从多口出现的现象会让二层网络很难受。

生产环境里 mode=3 极少见，我见过它出现在一些对丢包零容忍、对带宽不敏感的特殊系统里，比如某些定制化组播、金融行情分发、工业控制协议。这个模式下应用层必须能处理重复数据，或者干脆就是无状态广播协议。对绝大多数 Linux 服务器来说，如果既想要冗余又不想付带宽代价，mode=1 是更好的选择；如果既要冗余又要带宽，mode=4 是更好的选择。mode=3 更像是一种“执着于不丢包”的偏门方案，不建议常规业务使用。

2.5 mode=4 802.3ad：业界标准的 LACP 动态聚合

mode=4 是 802.3ad 标准动态链路聚合，也就是 LACP。它和 mode=0、mode=2 最大的区别在于，聚合关系不是“本地说了算”，而是通过 LACPDU 协议报文和对端交换机协商出来的。两端模式匹配、速率双工一致、成员口都在同一个 Eth-Trunk 或 PortChannel 里，链路才会被选中成为 active；任何一端配置不匹配，聚合都不会成立。这种协商机制避免了很多“配了 bond 但交换机不知道”的问题，是生产环境里做带宽叠加最推荐的方式。

bond 的 802.3ad 模式底下还可以调整负载均衡哈希策略，常见三种：layer2、layer2+3、layer3+4。默认是 layer2，只看 MAC；如果你的网络是三层环境，或者希望不同端口/不同会话能分散到不同物理链路，建议改成 layer2+3 或 layer3+4。需要特别提醒：虽然 mode=4 能叠加带宽，但这里叠加的是“多连接并发带宽”。单个 TCP 连接由于哈希固定，只会走其中一条成员链路，所以拿 iperf3 单线程测速是跑不满聚合带宽的，必须用多并发流来测。这一点很多第一次配 bond 的人都会误会。

2.6 mode=5 balance-tlb：发送均衡，接收还是单点

balance-tlb 是自适应发送负载均衡，TTLB 会自动根据每块成员网卡的实时负载情况，把发送流量分摊到不同的物理网卡上；但接收方向仍然由当前 active 网卡单独承担。换句话说，出站带宽可以叠加，入站带宽不能叠加。这个模式最大的好处是交换机不需要任何链路聚合配置，只要把两块网卡接到同一个二层广播域里就行，对现有网络改造成本几乎为零。

它适合什么场景？出站流量明显大于入站的业务。比如服务器往备份存储推数据、往对象存储上传日志、数据库向从库同步 binlog、视频推流等。这类流量方向单一，出站是瓶颈，入站反而没多少，mode=5 能用很轻的成本把出站带宽翻倍。要留意的是，因为发送流量会从不同物理网卡出来，交换机会看到同一个 MAC 地址出现在多个端口上，有些交换机默认开启端口安全或 MAC 防漂移策略，会把这类报文直接丢弃，所以接 mode=5 前要先在交换机侧确认没有这类限制。

2.7 mode=6 balance-alb：不需要交换机支持的“双向均衡”

balance-alb 可以理解为 balance-tlb 的增强版：发送方向依然做自适应负载均衡，接收方向额外通过 ARP 协商实现负载均衡。它会让 bond 在回应不同 ARP 请求时交替使用不同成员网卡的 MAC 地址作为源 MAC，这样一来，对端主机的 ARP 缓存里，同一个 IP 可能在不同时间对应不同的 MAC，流量就会被分散到多块物理网卡上。发送和接收两条方向都能叠加带宽，而且不需要交换机配置任何链路聚合协议。

听起来是不是很完美？但代价是复杂度和兼容性问题。它要求网卡驱动必须支持动态修改 MAC 地址，还要能发出 RARP 通告，绝大多数物理网卡没问题，但部分虚拟化环境、半虚拟化网卡、SR-IOV VF 可能不支持或行为异常。另外，ARP 表中的 MAC 频繁变化，对某些安全设备和防火墙来说可能触发告警，如果网络里有 ARP 检测策略，需要提前放行。如果不想改交换机，又必须双向增带宽，mode=6 是可以尝试的方案，但在上线前一定要做兼容性测试和长时间稳定性压测，不要直接上生产。

3. 不同发行版下的bond配置实战：从加载模块到开机自启

3.1 加载 bonding 模块：先搞清楚内核参数

配置 bond 的第一步是确保内核加载了 bonding 模块。大多数 Linux 发行版都自带这个模块，但参数需要在模块加载时指定。最简单的动态加载方式是这样：

# 查看模块是否已加载 lsmod | grep bonding # 动态加载 bonding 模块，指定 mode=1 miimon=100 modprobe bonding mode=1 miimon=100 # 如果模块已加载，可以动态创建一个 bond 接口 echo +bond0 > /sys/class/net/bonding_masters # 查看当前 bond 接口信息 cat /proc/net/bonding/bond0

生产环境不能只靠命令，因为重启后就没了。通常的做法是写进/etc/modprobe.d/bonding.conf：

alias bond0 bonding options bonding mode=1 miimon=100

这里的miimon=100表示每 100 毫秒检测一次链路状态，是链路检测的关键参数。如果网卡不支持 MII 链路检测，或者需要检测三层可达性，可以改用arp_interval=100 arp_ip_target=192.168.1.1，但 arp_ip_target 最多只能配 16 个 IP。要注意：如果用options bonding mode=...写在 modprobe 配置里，它会对所有 bond 接口生效。如果你在同一台机器上有两个 bond 且模式不同，就别在 modprobe 里写死 mode，等 bond 接口创建后再通过/sys/class/net/bondX/bonding/mode动态设置，或者直接在网络服务的配置里指定。

3.2 CentOS/RHEL 用 ifcfg 绑定的完整示例（含 NetworkManager 避坑）

CentOS 7/8 是 bond 配置最常见的环境。虽然现在都在推 NetworkManager，但传统 ifcfg 方式在运维脚本里仍然大量存在，而且能用network.service管理。以两块网卡 eth0、eth1 绑成 mode=1，bond0 配置 192.168.1.10/24 为例：

/etc/sysconfig/network-scripts/ifcfg-bond0：

DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes NAME=bond0 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.1.10 PREFIX=24 BONDING_OPTS="mode=active-backup miimon=100 primary=eth0"

/etc/sysconfig/network-scripts/ifcfg-eth0：

DEVICE=eth0 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes

/etc/sysconfig/network-scripts/ifcfg-eth1：

DEVICE=eth1 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes

然后执行：

systemctl restart network

注意几个容易翻车的地方。第一个是 slave 网卡上千万不要配 IP，也不要把NM_CONTROLLED=yes，否则 NetworkManager 会把这些网卡当成普通有线连接接管掉，重启后 bond 的成员关系可能丢失。第二个是如果服务器原本由 NetworkManager 管理，建议要么直接用nmcli的 bond 命令配置，要么在 slave 配置里明确写NM_CONTROLLED=no，避免两套网络服务抢网卡。第三个是BONDING_OPTS里的 mode 参数既可以用数字1，也可以用内核名称active-backup，两种写法都行，但要注意 802.3ad 模式对应写802.3ad而不是数字 4 时，不同发行版的解析能力略有差异，写成内核名称更保险。

如果你更习惯用 NetworkManager，也可以直接用一组命令完成：

nmcli con add type bond ifname bond0 mode active-backup miimon 100 primary eth0 nmcli con add type ethernet ifname eth0 master bond0 nmcli con add type ethernet ifname eth1 master bond0 nmcli con mod bond-bond0 ipv4.addresses 192.168.1.10/24 ipv4.method manual nmcli con up bond-bond0

这种方式在 RHEL/CentOS 8 以上更推荐，因为配置会自动纳入 NetworkManager 统一管理，开机能自启。

3.3 Ubuntu 用 netplan 配置 bond，顺便把开机自启一起解决

Ubuntu Server 18.04 以上默认用 netplan 管理网络。netplan 可以把 bond 配置得很干净，而且直接生成 systemd-networkd 的配置，天然解决开机自启问题。以两块网卡 enp1s0、enp2s0 绑成 mode=4 为例，配置写在/etc/netplan/01-netcfg.yaml：

network: version: 2 renderer: networkd ethernets: enp1s0: dhcp4: no enp2s0: dhcp4: no bonds: bond0: interfaces: [enp1s0, enp2s0] addresses: - 192.168.1.10/24 routes: - to: default via: 192.168.1.1 parameters: mode: 802.3ad mii-monitor-interval: 100 lacp-rate: fast transmit-hash-policy: layer3+4

写完执行netplan apply，然后用ip link show bond0和cat /proc/net/bonding/bond0验证。netplan 里mode: 802.3ad对应内核的 mode=4；如果想用 mode=1，就写mode: active-backup。lacp-rate: fast表示 LACP 报文每秒发一次，故障收敛更快，默认是 slow（30 秒），生产环境建议显式设成 fast。

如果你是老一点、还在用/etc/network/interfaces的 Ubuntu 或 Debian，也可以写：

auto bond0 iface bond0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 bond-slaves enp1s0 enp2s0 bond-mode 802.3ad bond-miimon 100 bond-lacp-rate 1

bond-lacp-rate 1同样表示 fast 模式。这个写法在 systemd-networkd 环境里也能被兼容，但 netplan 毕竟是现在 Ubuntu 的默认方案，能用新不用旧。

4. 模式选型：带宽、冗余和交换机能力怎么平衡

4.1 按业务场景选型：虚拟化、数据库、Web、存储

先给一个最容易上手的原则：拿不准就选 mode=1，或者选 mode=4。这两个模式是生产环境里最成熟、踩坑资料最多的选择。但如果你遇到的场景比较具体，可以这样分：

虚拟化宿主机上跑 KVM/VMware 虚拟机时，流量模型通常是“多虚拟机并发”，出站和入站都有压力，且宿主机一般接在支持 LACP 的接入交换机上，优先用 mode=4，并把 xmit_hash_policy 调成 layer3+4，让不同虚拟机之间的连接哈希到不同物理链路上。数据库双机、keepalived 这类场景，带宽需求不是第一位的，稳定性和故障切换的确定性才是，所以 mode=1 更合适，还可以配 primary 让主备角色清晰。Web 前端/负载均衡服务器则是典型的双向流量均衡需求，有 LACP 就上 mode=4，没有的话可以评估 mode=6。存储和备份服务器多为出站流量大、入站回包小，尤其像 NFS 大量并发连接时，mode=4 能发挥惰性；如果是单任务大文件备份、且无法支持多线程，那任何 bond 都不会让单流超过单网卡带宽。

4.2 最容易被忽略的交换机侧配置

很多人配 bond 只在服务器上折腾，忘了交换机也是聚合的一半。mode=0、2、3 都需要交换机把对应端口配成静态链路聚合，mode=4 需要交换机启用 LACP（Cisco 上是 channel-protocol lacp，华为/H3C 上是链路聚合模式为 lacp），mode=1、5、6 虽然不需要聚合，但要保证所有 slave 网卡接到同一个二层广播域里，也就是同一台交换机或同一个堆叠系统。别把一块网卡接到交换机 A、另一块接到没堆叠的交换机 B，否则 mode=6 的 ARP 负载均衡会让两台交换机都学到同一个 IP 对应不同的 MAC，流量会变得很诡异。

交换机上还要留意端口安全和 MAC 漂移策略。很多接入交换机默认会限制一个端口下 MAC 地址数量，或者检测到同一 MAC 从多个端口出现时直接丢弃。mode=5、mode=6 特别容易触发这种保护机制，上线前最好先把成员端口的安全策略关掉，或者将 bond 的 MAC 加入白名单。另外，如果交换机是堆叠环境，聚合成员口应该尽量分布在不同的堆叠成员交换机上，这样即使某一台设备出问题，聚合链路还能继续工作。

4.3 快速决策逻辑：把需求翻译成模式

如果你不想背每种模式的细节，可以按下面的问题做排除法。第一问：只做冗余，带宽够不够？够就用 mode=1。第二问：需要增加带宽，交换机能不能支持 LACP？能就用 mode=4。第三问：交换机不支持 LACP，但能做静态链路聚合？用 mode=2，别用 mode=0 和 mode=3，因为前者乱序严重，后者浪费带宽。第四问：交换机什么聚合都不想做，但还需要带宽叠加？出站为主用 mode=5，双向都要用 mode=6，但上线前必须验证网卡驱动和上层防火墙对 ARP 变化的容忍度。这个逻辑比死记表格要实用得多，我在评审 bond 方案时基本按这套顺序问自己。

5. 踩坑实录：配置bond后最容易翻车的四个问题

5.1 mode=4 链路明明起来了，业务却频繁丢包

有次给一组 KVM 宿主机配 mode=4，配完之后cat /proc/net/bonding/bond0显示 MII Status 全是 up，bond0 也能 ping 通。但跑业务时总有人反映访问偶发变慢，登录机器用 iperf3 多线程测速，发现带宽比单块网卡还差，而且观察成员网卡统计，只有其中一块在持续转发，另一块几乎没流量。

排查链路是这么走的：先用ip -d link show bond0确认 mode 确实是 802.3ad，再用ethtool enp2s0 | grep Speed确认两端速率都是千兆且双工一致，最后登上交换机看 LACP 协商状态，发现交换机上这几个端口根本没被加进同一个 Eth-Trunk，LACP 协商当然不成功。因为 802.3ad 模式下如果协商失败，bond 会退化成类似主备方式，只保留一块成员口转发。所以后面的验收流程里，我每次都会加一步：看交换机侧成员口是否都处于 Selected 状态，不要只看服务器端“看起来 up”。如果你用的是 Cisco，命令是show etherchannel summary；华为/H3C 是display eth-trunk verbose。

5.2 miimon 检测不到链路故障：拔线后切换花了 30 秒

另一个非常典型的坑是 miimon 检测到了 false positive。某台数据库服务器做了 mode=1 冗余，有一次计划内切换，拔掉 active 网卡的网线后，业务中断了整整 30 秒才恢复。按理说miimon=100应该 1 秒内完成切换，为什么这么慢？

查下来发现，服务器网卡到接入交换机之间还隔着一台光纤收发器。拔掉的是光纤收发器到交换机那侧的线，服务器网卡到光纤收发器之间其实是电气链路正常的，所以网卡的 MII 状态一直显示 up，bond 根本不知道远端已经断了。直到交换机侧的链路超时机制触发，才通过其他机制感知到故障。这个案例说明，链路检测层级的选取非常重要。如果接入链路中间有光电转换器、汇聚交换机等设备，纯 MII 检测是不够的，需要在 bond 里增加arp_interval和arp_ip_target，用三层可达性兜底。当然，增加 ARP 检测也要小心，目标 IP 要选真正稳定的网关或对端地址，否则误判反而更频繁。

5.3 重启后 bond 丢失：被 NetworkManager“抢走”的从设备

还有一个出现频率极高的重启故障：服务器配置好 bond 后一切正常，但只要一重启，ip addr看不到 bond0，或者 bond0 在但从设备没有加入。日志里能看到 NetworkManager 把 eth0、eth1 识别成了普通有线连接，并且自己生成了独立连接配置，这和传统 network.service 管理的 bond 产生了冲突。

解决这个问题有两种思路。如果你打算继续用传统 network.service，就在 slave 网卡的 ifcfg 文件里明确写NM_CONTROLLED=no，同时确认 systemd 中NetworkManager.service和network.service的启用关系。如果你想用 NetworkManager 管理，那就别混着写 ifcfg，直接像第 3.2 节那样用nmcli con add type bond和nmcli con add type ethernet master bond0建配置，让 NM 自己维护 slave 和 bond 的关系。最怕的就是两套配置都写一半，重启后互相打架。

5.4 balance-rr 单 TCP 流速度上不去，还疯狂重传

开头说的 mode=0 翻车案例，在这里补一下现场数据：双千兆 bond，用 iperf3 单线程打流，理论上应该接近 2Gbps，实际只有三四百兆，而且 TCP 重传率非常高。抓包后看到同一 seq 的包从 eth0、eth1 先后到达，对端不断回 DUP ACK，发送端触发快速重传，窗口一直缩，吞吐自然崩了。

这不是 bug，是 balance-rr 的固有特性。逐包轮询会把单个 TCP 流的报文分配到多条链路上，而多条链路的物理路径延迟不一致，就会乱序。TCP 协议为了确保数据顺序，会牺牲吞吐来等待重排。后来的处理方式是把业务切到 mode=4，并把 hash policy 改成 layer3+4，让不同 TCP 连接被分散到不同物理链路，同一连接始终走同一条链路，重传率立刻降下来了。这个案例给我的教训是：选 bond 模式前，一定要问业务一句“你的流量是多连接还是单连接”。单连接大流场景，任何基于连接的负载均衡都不能叠加带宽，只能靠换更大带宽的网卡或者应用层拆流。

6. 验证验收：如何确认 bond 真的在干活而不是“假聚合”

6.1 用 /proc/net/bonding 和 ethtool 确认状态

配置完 bond 之后，第一件事不是急着跑业务，而是确认状态。打开/proc/net/bonding/bond0，重点看这几个关键字段：Bonding Mode显示的是不是预期模式，MII Status是否全部为 up，Active Slave是不是预期的 active 网卡，Slave Interface列表里成员网卡是否都在。如果是 mode=4，还要看LACP rate是否为 fast，Transmit Hash Policy是否符合你的预期。

ip -d link show bond0也能看到 bond 的模式和成员关系，配合ethtool eth0检查每块物理网卡的速率、双工、link detected 是否正常。这里有个很容易误判的点：在 bond 接口上执行ethtool bond0，看到的 Speed 不一定是所有成员网卡的聚合值，它经常只反映某一块 active 网卡或第一个 slave 的速率，不能作为聚合成功的依据。真正需要确认的是每个 slave 网卡的状态，以及交换机侧聚合组是否完整。

6.2 拔线测试与带宽实测（iperf3 的正确用法）

bond 验收的核心是“破坏性测试”和“压测”。拔线测试要分两种情况看：如果是 mode=1/5/6，拔掉 active 网卡的线，bond 应该自动切换，ping 业务 IP 的丢包数越少越好，切换时间通常在秒以内；如果是 mode=4，拔掉一根成员口的线，聚合组里其他成员口会继续转发，业务基本无感。拔线前建议开一个持续 ping，让人在旁边盯输出，同时用watch -n 1 cat /proc/net/bonding/bond0观察切换过程。

带宽实测别只会跑iperf3 -c <server> -t 30，这条命令默认单线程，在 mode=2/4 下很难压出聚合带宽。正确做法是用-P参数开多并发流，例如：

# 服务端 iperf3 -s # 客户端，开 8 个并发流，测 30 秒 iperf3 -c 192.168.1.10 -P 8 -t 30 -i 2

想要更贴近真实业务，可以用-R测反向，或者用--bidir同时测双向。观察每块物理网卡的实时流量可以用sar -n DEV 1或ifstat，如果多块 slave 网卡的流量都明显上涨，说明负载均衡在生效；如果只有一块在涨，要么哈希策略没选对，要么交换机聚合没配好。

6.3 我的最后一条建议

管好 bond，本质上是一道“模式 + 链路检测 + 交换机聚合 + 哈希策略”的联合工程题，任何一个环节没对齐，线上就会以各种奇怪的方式表现出来。我现在的习惯是每次配置完 bond，都会做一次完整的拔线演练和多线程压测，并把结果记录到主机信息表里，注明模式、miimon、哈希策略、交换机型号和聚合状态。凡涉及 bond 变更，一定先备份 ifcfg 和 modprobe 配置，再在测试机里把相同模式跑一遍。虚拟机和物理机上的 bond 行为差异很大，尤其是半虚拟化网卡和虚拟交换机对 mode=6 的支持并不总是可靠，真正的生产验收还是要以物理机实测为准。这套流程走完，bond 才会真正成为你能放心依赖的底层能力。