Linux bond 七种 mode 详解：选型、配置与故障排查

1. 单网卡撑起一台服务器？先把风险摊开看

bond 技术及 mode 模式详解这个话题，我在运维岗上被问过不下二十次，问法各式各样，但落脚点基本都在同一处：手里那台服务器只有一块网口在扛全部流量，或者对端设备一掉线整个业务就断，怎么用改动最小的办法把这两件事一起解决。bond 是 Linux 内核自带的网卡绑定实现，把两张甚至更多物理网卡合并成一个逻辑网卡，对外只暴露一个设备名、一个 IP 地址，背后做冗余备份或者做流量分摊。mode 模式是 bonding 驱动提供的七种工作模式，编号 0 到 6，不同模式在链路聚合协议、负载算法、对交换机的要求上差别极大。选错了，要么两张网卡白搭、带宽一点没涨，要么直接把网络搞成半通不通的怪状态，排查起来能耗掉一整天。

这篇文章面向的是手里有 Linux 服务器、需要做网络高可用或者带宽叠加的朋友，不管是刚接手机房的新人，还是已经在维护几十台机器的老手，都能从里面找到可以直接抄的东西。我会从为什么需要 bond 讲到七种模式各自的原理，再讲到 miimon、xmit_hash_policy 这些参数到底怎么定，最后给出一套完整的配置流程和一份踩坑速查表。

1.1 网卡与链路是整台机器里最容易被忽略的单点

很多人做服务器冗余时，第一反应是双电源、RAID、集群，偏偏把网口落在最后。逻辑上可以理解，电源会坏、硬盘会坏，网卡“一般不坏”。但真实故障统计里，网口失效占比并不低，而且故障源根本不止网卡本身：光模块老化、光纤被压、跳线头松动、交换机端口 err-disable、机柜搬迁时线序搞错、上联板卡重启，任何一环出问题，表现都是同一件事——机器还在跑，业务连不上。

单网口的麻烦在于，它没有任何缓冲余地。CPU 可以多核、内存可以加、磁盘可以做 RAID，网络一旦物理断开，操作系统层面感知不到“我在裸奔”，只会安静地继续运行，直到监控告警或者用户投诉。更尴尬的是，有些场景下不是完全没有网，而是链路抖动、误码率飙高，表现为丢包和延迟尖刺，比彻底断开更难定位。

所以 bond 的第一个价值不在带宽，在把这条唯一的物理路径变成多条。这件事听起来简单，实际上要考虑的东西不少：备用链路什么时候接管、接管需要多久、接管之后对端设备（交换机、路由器、负载均衡）的 MAC 表和 ARP 缓存会不会乱、上层应用的长连接会不会断。这些问题的答案全都取决于你选了哪个 mode。

1.2 带宽叠加和链路冗余，是两件需要分开想清楚的事

新手最容易犯的认知错误，是认为“绑了两块千兆网卡，我就能跑 2000Mbps”。这句话对，也不对。对的部分是，在理想条件下聚合链路的总容量确实可以接近双口之和；不对的部分是，单条 TCP 连接的流量永远只能走其中一块网卡，因为 bonding 的负载分摊是按“流”做的哈希，不是按“包”做的切分。

举个具体的例子：两台服务器之间做一次大文件传输，用的是一条 TCP 连接，四元组固定不变，哈希结果固定，这条流就死死绑在某一块网卡上，最高只能跑到单口的线速。想真正吃满聚合带宽，要么开多线程并发传输，要么业务本身就是大量短连接（比如 Web 服务、对象存储），让哈希有足够多的样本去分摊。

理解了这一点，选型逻辑就清楚了。如果你的目标是“任何一块网卡挂了，业务无感”，那 mode 1 就够，配置最简单，对交换机也没要求。如果你的目标是“既要冗余，又希望总吞吐能上去，而且业务是并发型的”，那才需要考虑 mode 4 这类需要交换机配合的模式。把这两个目标混在一起谈，很容易做出一个配置复杂但收益为零的方案。

1.3 交换机侧的认知必须和服务器侧对齐

bond 出问题，八成以上的根因在交换机侧，而且往往是“我以为配了”。服务器上把两块网卡绑成 mode 4，交换机上对应的两个端口没有做链路聚合，结果就是：服务器这边看着 bond 接口状态正常，但只要一跑流量就开始大面积丢包、时通时断，甚至直接把交换机的 MAC 地址表冲爆，连累同网段的其他机器。

原因说穿了不复杂。mode 4 走的是 LACP，服务器会主动发协商报文，交换机不回，协商就不成立，Linux 这边不会启用这些端口，表现是 slave 状态起不来。但如果交换机配的是静态聚合（不跑 LACP），服务器配的是 mode 0 或 mode 2，双方都没有协商机制，谁都发现不了对端配错了，只能等流量上去以后用故障来暴露。这种“静默失败”是最难受的，因为环境看起来完全正常。

提示：凡是涉及多端口绑定的变更，服务器侧和交换机侧的配置必须当成一个整体来评审，最好在变更单上把两边的关键参数（模式、哈希策略、LACP 速率）都写清楚，别只写一句“做链路聚合”。

另外还有一类隐蔽问题：虚拟机环境。在虚拟化平台上给虚拟机配 bond 时，宿主机侧的虚拟交换机安全策略如果限制了 MAC 地址学习或者禁止伪装的报文，mode 6 这种依赖 ARP 协商修改对端缓存的模式会直接失效，表现是 bond 起来了但只有一块网卡在收包。这类问题在物理机上根本遇不到，排查时思路要换。

2. 七种 mode 模式的底层差异与选型逻辑

bonding 驱动提供的七种模式，本质上是三个维度的不同组合：出口选路策略（轮询、哈希、主备、广播）、故障检测方式（MII 链路层检测、ARP 探测）、是否依赖交换机协商。把这三点想明白，选型就是查表的事，不需要背。

下面逐组拆开说。这里我会把每种模式的报文走向讲清楚，因为很多“配置了没效果”的问题，根源就是没搞明白包到底从哪块网卡出去、又从哪块网卡进来。

2.1 mode 0 与 mode 1：最简单的两个极端

mode 0（balance-rr）是最朴素的轮询。内核给每个待发送的包按顺序分配出口，第一个包走 eth1，第二个走 eth2，第三个又回 eth1，如此循环。它的优点是负载最均匀，理论上可以把多块网卡的带宽叠加起来，连单条 TCP 连接都有可能受益，因为包被分散到了不同网卡上。

但代价也很明显：乱序。同一个 TCP 流的包从两条路径发出，经过不同的线缆、不同的交换机端口缓冲，到达对端的时间差可能超过接收窗口的容忍度，对端会判定为乱序，触发重传，实际吞吐往往比单网卡还低。所以在现代网络里，mode 0 基本只在特定场景下使用，比如两台机器直连、或者交换机做了严格的静态聚合且端口转发时延高度一致。普通生产环境我不推荐。

mode 1（active-backup）是另一头，只用一个网卡收发，其余网卡待命。活动网卡挂了，备用网卡在毫秒级接管，MAC 地址会跟着迁移过去（或者用 fail_over_mac 参数保持不变）。它的好处是：不需要交换机做任何配置，两块网卡甚至可以插在不同交换机上，实现真正的设备级冗余。代价是带宽完全没有叠加，永远只有一块网卡在工作。

这两者的选择其实反映了一个决策：你是要带宽还是要可用性。如果只能二选一，绝大多数业务系统应该选可用性，因为带宽不够顶多是慢，链路断了是直接不可用。

2.2 mode 2 与 mode 3：哈希分摊和广播复制

mode 2（balance-xor）在出口选择上用的是哈希，默认按源 MAC 与目的 MAC 做异或运算再对 slave 数量取模。相比 mode 0 的轮询，它的关键改进是同一条流永远走同一块网卡，因此不会产生乱序。这对 TCP 来说是好事，对负载均衡来说则意味着分摊粒度变粗，流数量少的场景下会出现“一条腿跑满、另一条腿闲着”。

mode 3（broadcast）更特殊，它把每个包都从所有 slave 上复制发出去一份。这个模式几乎只在极端容错场景下用，比如两台设备之间需要极高的送达概率，且对带宽浪费不敏感。它对交换机的要求是必须做聚合，否则同一个包从两个端口到达交换机，会把对端的 MAC 表搅乱。日常运维里我基本没见过生产环境用 mode 3，更多是作为教学或排查工具。

这两个模式都属于“需要交换机静态聚合配合”的类型，因为它们既不跑 LACP 协商，又会从多个端口发出源 MAC 相同的帧。交换机必须把这两个端口当成一个逻辑口来看待，否则生成树和 MAC 学习都会出问题。

2.3 mode 4：802.3ad 动态聚合，生产环境的主力

mode 4 是唯一一个实现了 IEEE 802.3ad 标准的动态链路聚合模式，也是我在生产环境里推荐最多的方案。它的工作方式是：服务器侧的 bonding 驱动作为 LACP 的主动方，周期性向交换机发送 LACPDU 协商报文，交换机回应，双方就端口速率、双工、聚合组达成一致之后，这些物理端口才真正加入聚合组，开始承载流量。

LACP 带来的最大好处是双方状态可见。交换机侧可以看到聚合组是否建立、每个成员口的状态、对端的系统优先级和端口优先级；服务器侧可以在/proc/net/bonding/bond0里看到 partner 的 MAC、每个 slave 的 LACP 状态。这种双向可见性让故障定位从“猜”变成“看”，价值远超过配置的那点复杂度。

几条硬性约束必须记住：成员口的速率和双工必须完全一致，千兆和万兆不能混在一个 mode 4 聚合组里；交换机侧必须显式配置 LACP 聚合（不同厂商叫法不同，有的叫动态链路聚合，有的叫 port-channel 加 LACP 模式）；如果两端都支持，LACP 速率建议设成 fast（每秒一次），故障切换感知能快一个数量级。

至于流量分摊，mode 4 同样依赖哈希，默认的 layer2 策略只看 MAC，在虚拟化环境下（大量虚拟机共用宿主机 MAC）分摊效果会很差，通常需要改成 layer3+4。

2.4 mode 5 与 mode 6：不依赖交换机配置的均衡方案

mode 5（balance-tlb）和 mode 6（balance-alb）是两个很有特色的模式，它们的卖点是交换机侧不需要任何配置，全靠服务器自己折腾。

mode 5 只做发送方向的负载均衡。它根据每块网卡的当前发送负载动态分配出口，接收方向则由当前活动网卡承担，其他网卡不参与接收。如果活动网卡挂了，另一个 slave 接管它的 MAC 地址继续接收。这个模式对交换机唯一的要求是端口要能学到多个 MAC（一般默认就支持），但接收侧仍然是单点。

mode 6 在 mode 5 基础上增加了接收负载均衡，实现方式有些取巧：bonding 驱动周期性向网络里的对端发送 ARP 请求，用的源 MAC 是各个 slave 的 MAC，这样对端的 ARP 缓存和交换机的 MAC 表就会被逐步“引导”，让不同的对端把回程流量发到不同的 slave 上。听起来巧妙，实际效果取决于网络里对端设备的数量和 ARP 缓存行为，如果对端只有一台核心网关，收效有限。

这两个模式对网卡驱动有要求，需要驱动支持 ethtool 的设置接口，主流服务器网卡基本都满足。它们的适用场景是：交换机不受你控制（比如托管机房、云上虚拟机），但又想要一定的负载均衡。代价是排障难度高，出问题时现象不直观，需要抓 ARP 报文才能看清。

2.5 七种模式的横向对比

表格只能给出方向，真正定下来还得看三件事：交换机能不能配、业务是不是并发型、故障切换时间要求是多少。我个人的默认选择是——能配 LACP 就用 mode 4，不能就退到 mode 1 保可用，中间的 mode 2 只有在明确知道交换机做不了 LACP 且业务流数量足够多时才会考虑。

3. 关键参数怎么定：miimon、哈希策略与 LACP 速率

模式选对了，参数配错一样白搭。bonding 的参数有二十多个，但真正影响行为的其实就那么五六个。这一节我会把每个参数的取值逻辑写清楚，包括为什么是这个数、改了会有什么后果。

3.1 链路检测：miimon 和 arp_interval 只能二选一

miimon 是 MII 链路监视，单位毫秒，它的作用是让驱动每隔这么长时间去读一次网卡的物理层状态寄存器，看看载波信号还在不在。这是最轻量的检测方式，几乎不产生网络流量，默认值通常是 100。

这个 100 是怎么来的？如果设得太小，比如 10，驱动会非常频繁地打断正常收发包流程，在低配机器上能看到明显的 CPU 占用上升，极端情况下还会误判。如果设得太大，比如 1000，那么链路断了以后最长要一秒才能发现，加上切换动作，业务侧可能感知到一到两秒的中断。100 毫秒是一个折中：单次切换通常在 200 毫秒以内完成，对绝大多数 TCP 应用来说不会触发超时重连。

和 miimon 配套的还有 updelay 和 downdelay，单位同样是毫秒，分别表示“链路恢复后等待多久才启用”和“链路断开后等待多久才判定失效”。这两个参数的意义在于抑制抖动：光模块接触不良时链路会反复 up/down，如果不做延时，bond 会疯狂切换，MAC 地址表被反复刷新，反而制造更大范围的问题。我一般会设 updelay=200、downdelay=200，让抖动被过滤掉。

arp_interval 是另一套机制，靠周期性向指定目标（arp_ip_target）发 ARP 请求并等待回应来判断链路是否可用。它的优势是能发现“物理层正常但对端已经死掉”的情况，比如中间经过交换机、对端网卡假死，此时 MII 状态还是 up 的，miimon 完全看不出来。代价是需要指定一个可靠的探测目标 IP，而且会产生额外的 ARP 流量。

注意：miimon 和 arp_interval 不能同时生效，写配置时如果两个都填了，后者会被忽略或者行为不确定。选一个就行，常规场景用 miimon，跨设备、跨机房的复杂链路上才考虑 arp。

3.2 xmit_hash_policy：决定你能不能真的叠出带宽

这个参数是 mode 2、mode 4 的灵魂，也是被误解最多的一个。它定义了出口哈希怎么算，直接决定了流量能不能被分摊开。

默认值是 layer2，算法大致是把源 MAC 和目的 MAC 做异或后取模。在物理机场景下问题不大，但虚拟化环境里所有虚拟机的流量都从宿主机的 bond 出去，源 MAC 是宿主机的，目的 MAC 通常是网关的，这两个值固定不变，哈希结果恒定，所有流量全压在一块网卡上。这就是为什么很多人在虚拟机环境里配了 mode 4，测速发现带宽一点没涨。

改成 layer3+4 之后，哈希会同时纳入源 IP、目的 IP、源端口、目的端口，四元组的组合数一下子就上去了，不同虚拟机访问不同服务会被分到不同网卡。这个策略的代价是：对于分片报文和非 TCP/UDP 协议（比如 ICMP），驱动无法取到端口信息，会退回到只用 IP 计算。另外，如果业务本身是单一的大流量连接（比如一次备份传输），改了也没用，因为四元组还是固定的。

layer2+3 是折中方案，同时用 MAC 和 IP，不考虑端口，适合那种 IP 分布广但端口固定的场景。我的实践是：物理机 + 大量短连接，默认 layer2 就够；虚拟化环境或者容器环境，无脑上 layer3+4。

改这个参数有个前提：同一条流的所有包必须走同一块网卡，否则会乱序。xmit_hash_policy 的算法是确定性的，只要四元组不变，算出来的结果就不变，这一点是有保证的。但要注意，如果中途某个 slave 掉了，哈希的取模基数变了，原本的流会被重新分配到别的网卡上，这是一次短时的乱序来源，属于可接受的代价。

3.3 lacp_rate、ad_select 与 fail_over_mac

lacp_rate 只对 mode 4 有效，取值 slow 或 fast。slow 是每 30 秒发一次 LACPDU，fast 是每秒一次。这个参数影响的是故障发现速度：交换机的某个端口挂了，如果 LACP 报文 30 秒才交互一次，服务器可能要等到下一次超时（通常是 3 倍报文周期，即 90 秒）才能确认对端失效。设成 fast 的话，3 秒内就能发现。

所以只要交换机支持，mode 4 一定配 fast。有些老型号交换机对 fast 支持不好，协商不起来，那就只能退回 slow，此时要接受更长的切换时间。

ad_select 决定 mode 4 下如何挑选活动聚合器，有 stable、bandwidth、count 三个值。stable 是默认值，选第一个协商成功的聚合器；bandwidth 选总带宽最大的；count 选 slave 数量最多的。绝大多数场景 stable 就够，只有在多机箱聚合（一个聚合组跨两台交换机）这种复杂拓扑下，bandwidth 或 count 才有意义。

fail_over_mac 是给 mode 1 用的，控制故障切换时 MAC 地址的行为。none 是默认，切换时 MAC 跟着迁移到新的活动网卡；active 是始终使用第一块网卡的 MAC，不让它变；follow 是切换后把 MAC 设到新网卡上。为什么需要这个参数？因为某些交换机或上层设备有 MAC 绑定策略，不允许同一个 IP 对应不同 MAC，这时候用 active 可以让对端完全感知不到切换发生。代价是：如果第一块网卡彻底坏了，MAC 就无处安放，bond 会一直不完整，所以 active 只适合“网卡只是链路抖动”的场景。

3.4 一套可以直接抄的参数模板

把上面的逻辑收敛一下，我给两组常用配置。数据中心内部、交换机可配的机器：

# mode 4 + 毫秒级链路检测 + 四元组哈希 + 快速 LACP BONDING_OPTS="mode=4 miimon=100 updelay=200 downdelay=200 \ xmit_hash_policy=layer3+4 lacp_rate=fast ad_select=stable"

交换机不可控、只需要保可用的机器：

# mode 1 + 主备 + 抑制抖动 BONDING_OPTS="mode=1 miimon=100 updelay=200 downdelay=200 primary=eth1"

primary 参数指定首选活动网卡，让流量固定从某块网卡走，只有在它失效时才切换。这么做的好处是可预测，排查的时候不用猜现在走的是哪条腿。缺点是两块网卡的磨损和流量不均衡，但对大多数场景来说，可预测性比这点均衡更重要。

参数改完不需要重启系统，但需要重新加载 bond 接口。生产环境上的操作窗口要提前约好，因为重载期间网络会短暂中断。临时调整可以走 sysfs，比如改哈希策略：

echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

这种改法重启就没了，只适合验证效果，最终还是要落到配置文件里。

4. 从零配一个 mode 4 并做故障演练

原理和参数讲完了，接下来走一遍完整流程。我按“交换机准备、服务器配置、验证、演练”四步来写，每一步都说明为什么这么做，以及做错了会怎样。这里假设的场景是：一台双网卡服务器，接在同一台接入交换机的两个相邻端口上，需要配置成 mode 4，同时在上面跑业务 IP。

4.1 交换机侧先把聚合组建起来

顺序很关键，先配交换机再配服务器。原因在于 mode 4 的 LACP 协商是由服务器主动发起的，如果服务器先配好、交换机还没建组，服务器会一直发协商报文但收不到回应，端口保持不可用状态，这段时间里机器相当于网络断开。反过来，交换机先建好组等待协商，服务器一配就能立刻完成，中断窗口最短。

交换机侧的配置要点有四个：第一，两个物理端口必须加入同一个聚合组；第二，聚合模式必须选动态（LACP），不是静态；第三，两个端口的速度、双工、VLAN 配置必须完全一致；第四，如果交换机支持，把生成树相关的端口设置为边缘端口或者关闭该聚合组参与生成树计算，避免链路起来后还要等几十秒收敛。

配置完成后，交换机的聚合组状态应该是 down 或者等待协商，因为在服务器侧还没起来。这时候可以准备服务器配置了。

4.2 NetworkManager 与传统 ifcfg 两套写法

现在主流发行版分两派：一派用 NetworkManager 管理网络，另一派保留了传统的 network-scripts。两套都要会，因为你永远不知道客户现场是哪一套。

先看 NetworkManager 的写法。它的好处是一条命令搞定，而且配置持久化不依赖文件编辑：

# 创建 bond 接口 nmcli con add type bond con-name bond0 ifname bond0 \ mode 802.3ad \ bond.options "miimon=100,updelay=200,downdelay=200,xmit_hash_policy=layer3+4,lacp_rate=fast" # 配置 IP nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1 # 把两块物理网卡加进去 nmcli con add type ethernet con-name bond0-slave1 ifname eno1 master bond0 nmcli con add type ethernet con-name bond0-slave2 ifname eno2 master bond0 # 启用 nmcli con up bond0

注意mode这个字段在 nmcli 里用的是英文名称802.3ad，不是数字 4，写错了会报错。另外 slave 的类型必须是ethernet且指定master，不能先给物理网卡配 IP 再加进去，否则会有残留路由。

再看传统 ifcfg 写法，需要三个文件。第一个是 bond 本体：

# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none IPADDR=192.0.2.10 PREFIX=24 GATEWAY=192.0.2.1 ONBOOT=yes BONDING_OPTS="mode=4 miimon=100 updelay=200 downdelay=200 xmit_hash_policy=layer3+4 lacp_rate=fast"

第二个和第三个是两块物理网卡，内容除设备名外完全一样：

# /etc/sysconfig/network-scripts/ifcfg-eno1 DEVICE=eno1 TYPE=Ethernet BOOTPROTO=none MASTER=bond0 SLAVE=yes ONBOOT=yes

这里有个容易忽略的细节：物理网卡的配置文件里绝对不能有 IPADDR、GATEWAY 这些字段，也不能有NM_CONTROLLED=no之类的干扰项。一旦有残留 IP，网卡本身会带着地址活在 bond 之下，路由表出现重复条目，表现是偶发丢包或者 ping 不通。改完配置后用systemctl restart network或者nmcli con reload生效，中间会断几秒。

注意：如果服务器上还跑着虚拟化，需要把 bond0 挂到网桥上，顺序必须是先建 bond、再加成 bridge 的端口，不能反过来。网桥对 bond 是“上层”，搞反了会看到 bridge 一直处于 no-carrier 状态。

4.3 状态核对与压测验证

配置生效后第一件事不是急着测速，是看状态对不对。核心文件是/proc/net/bonding/bond0：

cat /proc/net/bonding/bond0

输出里要重点看几行。Bonding Mode: IEEE 802.3ad Dynamic link aggregation确认模式正确；MII Status: up确认整体链路正常；每个 slave 下面应该有MII Status: up、Speed: 10000 Mbps、Duplex: full；最关键的是Partner Mac Address，如果这个值是全零，说明 LACP 协商根本没成功，交换机侧配置有问题。

mode 4 还有个特殊字段是LACP rate，应该显示为 fast。如果显示 slow 但你配了 fast，说明交换机不接受 fast，需要回头查交换机配置或固件。

确认状态正常后开始压测。这里有个方法论问题：单线程 iperf3 测不出聚合带宽，因为那是一条流。要用多线程：

# 服务端 iperf3 -s # 客户端，开 8 条并发流 iperf3 -c 192.0.2.20 -P 8 -t 30

8 条流的情况下，如果哈希策略是 layer3+4，理论上应该能看到接近双口总带宽的结果。如果还是单口速度，先看ip -s link show bond0和各物理网卡的收发计数，确认流量到底走了哪条腿；再确认 iperf3 的 8 条连接是不是真的用了不同的源端口（通常是的，因为临时端口是随机分配的）。

这里还有一个坑：某些网卡开启了 GRO、TSO 等卸载特性，在 bond 之下的行为可能和预期不同，理论上不会影响哈希结果，但如果发现流量分布不均，可以临时关掉这些特性再测一次，用来排除干扰。

4.4 拔线演练，别等真故障的时候才第一次验证

配置完成不等于方案可用，必须主动做一次故障演练。做法是：在压测的同时，物理拔掉一根网线（或者用交换机侧 shutdown 端口，后者更接近真实故障），观察三件事。

第一，丢包数量。在另一个终端持续 ping，统计切换期间丢了多少个包。mode 4 配了 fast LACP，正常情况下应该在个位数，如果丢了上百个包，说明切换逻辑有问题，多半是 updelay/downdelay 设置不当或者交换机侧收敛慢。

第二，/proc/net/bonding/bond0的状态变化。被拔掉的 slave 应该显示MII Status: down，另一个 slave 接替成为活动状态。恢复网线后，要确认它能不能自动重新加入聚合组，有些环境下需要手工触发。

第三，业务侧的表现。如果用长连接做测试，会看到连接在切换瞬间卡顿一下然后恢复；如果用短连接，可能完全无感。这个差异要提前告知业务方，避免他们在故障后质疑方案有效性。

演练做完，把结果记录下来——切换耗时、丢包数、恢复时间，这份记录在后续变更评审和故障复盘时非常有用。

5. 故障排查速查表与踩坑记录

配置这件事，做对了就是一次性的，做错了就是一个持续消耗时间的黑洞。这一节我把这几年遇到的典型问题整理一下，按现象归类，方便出问题时对号入座。

5.1 五种高频现象怎么定位

现象一：bond 接口能起来，但完全不通。先去/proc/net/bonding/bond0看 Partner Mac Address，全零就是 LACP 没协商成功。此时八成是交换机端口没加入聚合组，或者加入了但模式选成了静态。另一个可能是两端速率不匹配，比如服务器网卡自适应成了千兆，交换机端口固定万兆。

现象二：能通，但速度只有单口。先确认是不是单条流在跑，单流本来就只能走一块网卡。如果确认是多流还是单口速度，去看xmit_hash_policy，虚拟化环境下默认的 layer2 几乎必然导致这个问题。改完记得验证是否生效，用cat /sys/class/net/bond0/bonding/xmit_hash_policy确认。

现象三：时通时断，ping 有大量丢包。这种最典型的原因是交换机侧没做聚合而服务器侧配了 mode 0/2/3。交换机看到同一个 MAC 从两个端口进来，MAC 表在两个端口之间反复横跳，转发就乱了。还有一种可能是链路本身有误码，用ethtool -S eno1看 CRC 错误计数，如果持续增长就是物理层问题，换线换模块。

现象四：切换后业务恢复不了。这通常是 ARP 缓存的问题。mode 1 切换时 MAC 迁移到新网卡，但上游设备（交换机、防火墙、负载均衡）的 ARP 表还指向旧端口，需要等老化或者主动发免费 ARP 才能纠正。可以在 bond 参数里加num_grat_arp=5，让切换后主动广播几次，加速对端更新。

现象五：bond 起来了，但虚拟化环境里的虚拟机网络异常。先确认宿主机侧的虚拟交换机是否允许 bond 成员口所需的报文通过，特别是 mode 6 依赖的 ARP 报文和 MAC 学习。再检查虚拟机的网卡是否绑到了正确的 bridge 上，这个链条一长就容易断在某处。

5.2 排查动作速查表

这张表不是万能的，但它能覆盖八成的现场情况。真正的定位还是要靠抓包和日志，tcpdump -i bond0 -n arp能看到 ARP 协商过程，dmesg | grep -i bond能看到驱动的状态变化日志。

5.3 几条不太会写在文档里的经验

经验一：变更前一定要记录基线。配置之前的/proc/net/bonding/bond0、路由表、邻接表，全都截图保存。出问题的时候，对比基线是最快的定位方式，比凭空回忆强得多。

经验二：别在业务高峰期做 bond 变更。即使理论上切换是毫秒级的，实际操作中涉及接口重建、路由重算，中断时间可能是秒级甚至更长。我见过一次在交易时段改配置，触发了上游防火墙的会话表刷新，导致大批长连接断开的案例。

经验三：配了 bond 不等于可以不管了。我遇到过一台机器，两块网卡都插在同一个交换机上，交换机整机重启的时候，bond 完全没起作用。所以配 bond 之前先想清楚要防的是什么故障：防网卡坏，插同一台交换机可以；防交换机坏，必须跨设备，此时只能用 mode 1 或者跨机箱聚合。

经验四：文档里写清楚“为什么是这个模式”。半年后接手的人看到 mode 2，第一反应可能是“为什么不升到 mode 4”，然后就去改了。如果配置注释里写明“交换机不支持 LACP，故用静态聚合”，这个坑就不会被重复踩。

经验五：监控要跟上。bond 的 slave 状态变化在系统日志里是有记录的，但很容易被淹没。把MII Status和每个 slave 的 up/down 做成监控指标，链路一抖就能收到告警，比等用户反馈快得多。同时把xmit_hash_policy和模式也纳入配置基线核查，防止有人手工改动后没同步到配置文件。

我个人在实际操作中的体会是，bond 这件事技术本身不难，难在它横跨了服务器和网络两个领域，而这两个领域的运维往往是两拨人。配置之前多花十分钟和网络侧对齐参数，能省掉后面几天的扯皮。至于模式选择，别追求“最先进”，稳定可解释比性能极限重要得多，一台能跑满单口但永远在线的机器，比一台理论带宽翻倍但每月抖一次的机器有价值。