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 0balance-rr是最朴素的轮询。内核给每个待发送的包按顺序分配出口第一个包走 eth1第二个走 eth2第三个又回 eth1如此循环。它的优点是负载最均匀理论上可以把多块网卡的带宽叠加起来连单条 TCP 连接都有可能受益因为包被分散到了不同网卡上。但代价也很明显乱序。同一个 TCP 流的包从两条路径发出经过不同的线缆、不同的交换机端口缓冲到达对端的时间差可能超过接收窗口的容忍度对端会判定为乱序触发重传实际吞吐往往比单网卡还低。所以在现代网络里mode 0 基本只在特定场景下使用比如两台机器直连、或者交换机做了严格的静态聚合且端口转发时延高度一致。普通生产环境我不推荐。mode 1active-backup是另一头只用一个网卡收发其余网卡待命。活动网卡挂了备用网卡在毫秒级接管MAC 地址会跟着迁移过去或者用 fail_over_mac 参数保持不变。它的好处是不需要交换机做任何配置两块网卡甚至可以插在不同交换机上实现真正的设备级冗余。代价是带宽完全没有叠加永远只有一块网卡在工作。这两者的选择其实反映了一个决策你是要带宽还是要可用性。如果只能二选一绝大多数业务系统应该选可用性因为带宽不够顶多是慢链路断了是直接不可用。2.2 mode 2 与 mode 3哈希分摊和广播复制mode 2balance-xor在出口选择上用的是哈希默认按源 MAC 与目的 MAC 做异或运算再对 slave 数量取模。相比 mode 0 的轮询它的关键改进是同一条流永远走同一块网卡因此不会产生乱序。这对 TCP 来说是好事对负载均衡来说则意味着分摊粒度变粗流数量少的场景下会出现“一条腿跑满、另一条腿闲着”。mode 3broadcast更特殊它把每个包都从所有 slave 上复制发出去一份。这个模式几乎只在极端容错场景下用比如两台设备之间需要极高的送达概率且对带宽浪费不敏感。它对交换机的要求是必须做聚合否则同一个包从两个端口到达交换机会把对端的 MAC 表搅乱。日常运维里我基本没见过生产环境用 mode 3更多是作为教学或排查工具。这两个模式都属于“需要交换机静态聚合配合”的类型因为它们既不跑 LACP 协商又会从多个端口发出源 MAC 相同的帧。交换机必须把这两个端口当成一个逻辑口来看待否则生成树和 MAC 学习都会出问题。2.3 mode 4802.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分摊效果会很差通常需要改成 layer34。2.4 mode 5 与 mode 6不依赖交换机配置的均衡方案mode 5balance-tlb和 mode 6balance-alb是两个很有特色的模式它们的卖点是交换机侧不需要任何配置全靠服务器自己折腾。mode 5 只做发送方向的负载均衡。它根据每块网卡的当前发送负载动态分配出口接收方向则由当前活动网卡承担其他网卡不参与接收。如果活动网卡挂了另一个 slave 接管它的 MAC 地址继续接收。这个模式对交换机唯一的要求是端口要能学到多个 MAC一般默认就支持但接收侧仍然是单点。mode 6 在 mode 5 基础上增加了接收负载均衡实现方式有些取巧bonding 驱动周期性向网络里的对端发送 ARP 请求用的源 MAC 是各个 slave 的 MAC这样对端的 ARP 缓存和交换机的 MAC 表就会被逐步“引导”让不同的对端把回程流量发到不同的 slave 上。听起来巧妙实际效果取决于网络里对端设备的数量和 ARP 缓存行为如果对端只有一台核心网关收效有限。这两个模式对网卡驱动有要求需要驱动支持 ethtool 的设置接口主流服务器网卡基本都满足。它们的适用场景是交换机不受你控制比如托管机房、云上虚拟机但又想要一定的负载均衡。代价是排障难度高出问题时现象不直观需要抓 ARP 报文才能看清。2.5 七种模式的横向对比模式编号名称出口策略接收分担交换机要求带宽叠加典型场景0balance-rr轮询是静态聚合强建议是但乱序直连、特殊测试1active-backup主备否无否通用高可用、跨机架冗余2balance-xor哈希是静态聚合是按流无 LACP 支持的交换机3broadcast全播是静态聚合否极端容错4802.3ad哈希是必须 LACP是按流生产主力、数据中心5balance-tlb发送动态否无仅发送侧交换机不可控场景6balance-alb收发动态是无需学多 MAC部分交换机不可控且并发高表格只能给出方向真正定下来还得看三件事交换机能不能配、业务是不是并发型、故障切换时间要求是多少。我个人的默认选择是——能配 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 地址表被反复刷新反而制造更大范围的问题。我一般会设 updelay200、downdelay200让抖动被过滤掉。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测速发现带宽一点没涨。改成 layer34 之后哈希会同时纳入源 IP、目的 IP、源端口、目的端口四元组的组合数一下子就上去了不同虚拟机访问不同服务会被分到不同网卡。这个策略的代价是对于分片报文和非 TCP/UDP 协议比如 ICMP驱动无法取到端口信息会退回到只用 IP 计算。另外如果业务本身是单一的大流量连接比如一次备份传输改了也没用因为四元组还是固定的。layer23 是折中方案同时用 MAC 和 IP不考虑端口适合那种 IP 分布广但端口固定的场景。我的实践是物理机 大量短连接默认 layer2 就够虚拟化环境或者容器环境无脑上 layer34。改这个参数有个前提同一条流的所有包必须走同一块网卡否则会乱序。xmit_hash_policy 的算法是确定性的只要四元组不变算出来的结果就不变这一点是有保证的。但要注意如果中途某个 slave 掉了哈希的取模基数变了原本的流会被重新分配到别的网卡上这是一次短时的乱序来源属于可接受的代价。3.3 lacp_rate、ad_select 与 fail_over_maclacp_rate 只对 mode 4 有效取值 slow 或 fast。slow 是每 30 秒发一次 LACPDUfast 是每秒一次。这个参数影响的是故障发现速度交换机的某个端口挂了如果 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_OPTSmode4 miimon100 updelay200 downdelay200 \ xmit_hash_policylayer34 lacp_ratefast ad_selectstable交换机不可控、只需要保可用的机器# mode 1 主备 抑制抖动 BONDING_OPTSmode1 miimon100 updelay200 downdelay200 primaryeth1primary 参数指定首选活动网卡让流量固定从某块网卡走只有在它失效时才切换。这么做的好处是可预测排查的时候不用猜现在走的是哪条腿。缺点是两块网卡的磨损和流量不均衡但对大多数场景来说可预测性比这点均衡更重要。参数改完不需要重启系统但需要重新加载 bond 接口。生产环境上的操作窗口要提前约好因为重载期间网络会短暂中断。临时调整可以走 sysfs比如改哈希策略echo layer34 /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 miimon100,updelay200,downdelay200,xmit_hash_policylayer34,lacp_ratefast # 配置 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 DEVICEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOnone IPADDR192.0.2.10 PREFIX24 GATEWAY192.0.2.1 ONBOOTyes BONDING_OPTSmode4 miimon100 updelay200 downdelay200 xmit_hash_policylayer34 lacp_ratefast第二个和第三个是两块物理网卡内容除设备名外完全一样# /etc/sysconfig/network-scripts/ifcfg-eno1 DEVICEeno1 TYPEEthernet BOOTPROTOnone MASTERbond0 SLAVEyes ONBOOTyes这里有个容易忽略的细节物理网卡的配置文件里绝对不能有 IPADDR、GATEWAY 这些字段也不能有NM_CONTROLLEDno之类的干扰项。一旦有残留 IP网卡本身会带着地址活在 bond 之下路由表出现重复条目表现是偶发丢包或者 ping 不通。改完配置后用systemctl restart network或者nmcli con reload生效中间会断几秒。注意如果服务器上还跑着虚拟化需要把 bond0 挂到网桥上顺序必须是先建 bond、再加成 bridge 的端口不能反过来。网桥对 bond 是“上层”搞反了会看到 bridge 一直处于 no-carrier 状态。4.3 状态核对与压测验证配置生效后第一件事不是急着测速是看状态对不对。核心文件是/proc/net/bonding/bond0cat /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 308 条流的情况下如果哈希策略是 layer34理论上应该能看到接近双口总带宽的结果。如果还是单口速度先看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_arp5让切换后主动广播几次加速对端更新。现象五bond 起来了但虚拟化环境里的虚拟机网络异常。先确认宿主机侧的虚拟交换机是否允许 bond 成员口所需的报文通过特别是 mode 6 依赖的 ARP 报文和 MAC 学习。再检查虚拟机的网卡是否绑到了正确的 bridge 上这个链条一长就容易断在某处。5.2 排查动作速查表现象首要检查点命令或文件常见根因完全不通LACP 协商状态/proc/net/bonding/bond0的 Partner Mac交换机未配聚合组速度不达标哈希策略与流数量xmit_hash_policy、iperf3 -P 8layer2 策略 单流丢包抖动交换机聚合模式交换机端口配置静态/动态模式不匹配切换慢LACP 速率与延时参数lacp_rate、updelayslow 模式或延时过大切换后不通ARP 缓存上游设备 ARP 表MAC 迁移未通知单口收包异常网卡错误计数ethtool -S iface光模块或线缆故障这张表不是万能的但它能覆盖八成的现场情况。真正的定位还是要靠抓包和日志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 这件事技术本身不难难在它横跨了服务器和网络两个领域而这两个领域的运维往往是两拨人。配置之前多花十分钟和网络侧对齐参数能省掉后面几天的扯皮。至于模式选择别追求“最先进”稳定可解释比性能极限重要得多一台能跑满单口但永远在线的机器比一台理论带宽翻倍但每月抖一次的机器有价值。