Linux网卡bond七种模式详解：原理、选型与避坑指南

网卡绑定这件事，说简单也简单，说坑多也是真的多。我在机房蹲过整夜排查一个"明明配置了主备却死活不切换"的问题，最后发现是交换机端口没做对应配置；也见过有人把七种模式当成七个选项随便挑一个填上去，结果业务跑起来带宽没涨、故障反而更频繁。Linux网卡bond（绑定）的七种模式，表面上是七个数字，背后其实是三套完全不同的工作逻辑：一套是"一主一备"的高可用思路，一套是"多路并行"的负载均衡思路，还有一套是"聚合协商"的链路层协议思路。搞不清楚这个分类，配置写得再漂亮也是碰运气。

这篇内容面向的是需要在实际服务器上落地网卡绑定的运维、后端和系统集成人员，也适合刚接触网络配置、想把bond七种模式一次搞明白的朋友。我会把每种模式的报文走向、协商机制、对交换机的要求、适用场景和踩坑点都拆开讲，重点放在"为什么这么选"和"配下去之后怎么验证"这两件事上。文中涉及的命令和参数都可以直接照着改，但请务必先在测试环境验证，尤其是涉及交换机侧配置的部分。

1. 先搞清楚bond到底在解决什么问题

1.1 单网卡的三重脆弱性

一台服务器只有一块物理网卡对外提供服务，本质上是在赌三件事同时成立：这块网卡不坏、这根网线不松、这个交换机端口不出问题。任何一环出状况，业务就直接断。单网卡的脆弱性可以拆成三个层面来看。

第一层是物理层单点。网卡芯片、光模块、网线、交换机端口，任何一个环节的硬件故障都会导致链路中断。这类故障的概率单看都不高，但服务器数量一多，按年化算下来就是必然事件。第二层是带宽天花板。一块千兆网卡的理论上限就是1000Mbps，实际跑满还要打折，遇到备份窗口、大文件传输、虚拟化迁移这类突发流量，单卡很容易成为瓶颈。第三层是维护窗口。换网卡、换线、交换机升级，只要涉及那块唯一的网卡，就必须停机。

bond的价值就在于把多块物理网卡在系统层面"捏"成一个逻辑接口。对上层应用来说，它看到的始终是一个名叫bond0（或自定义名称）的网卡，IP、路由、防火墙规则都绑在这个逻辑接口上。底层物理网卡怎么增减、怎么切换，上层无感。这就同时缓解了上面三个问题：冗余解决单点故障，聚合提升带宽上限，热切换减少维护停机。

1.2 逻辑接口与物理接口的关系

理解bond的关键，是分清"逻辑接口"和"物理接口"这两层。物理接口就是eth0、eth1、ens33这类真实存在的网卡，它们各自有MAC地址、各自连着交换机的一个端口。逻辑接口是bond0，它有自己的MAC地址（默认取第一块加入的物理网卡的MAC，也可以手动指定），有自己的IP配置。

数据从应用层下来，先到bond0这个逻辑接口，由bond驱动根据当前模式决定从哪块（或哪几块）物理网卡发出去。反方向上来的包，也由驱动决定怎么交给bond0。这个"决定"的过程，就是七种模式的核心差异所在。所以配置bond从来不是只改系统侧，交换机侧往往要配合，因为交换机看到的是多根独立的线连着多个端口，它得知道这些端口背后其实是同一台机器。

提示：bond0的MAC地址在模式切换或成员变更时可能发生变化，如果上层有基于MAC的绑定策略（比如某些授权、DHCP保留），建议用bond0配置里的hwaddr显式固定，避免切换后地址漂移。

1.3 七种模式的分类逻辑

七种模式（mode 0到mode 6）不是并列的七个选项，按工作逻辑可以归成三类，这个分类是后面所有选型判断的基础。

主备类的思路是"备而不用"，牺牲带宽换简单可靠；负载均衡类的思路是"多路并行"，追求吞吐但引入复杂性；动态协商类是"和交换机商量着来"，标准化程度最高但对设备有要求。选型时先问自己：我要的是故障不断还是带宽叠加？这个问题的答案基本就把范围缩小到一类了。

2. 七种模式逐个拆解：报文怎么走、什么时候用

2.1 mode 0：轮询负载均衡，最直接也最挑交换机

mode 0叫balance-rr，工作方式非常朴素：发出去的包按顺序轮流从每块成员网卡走，第一块、第二块、第三块……循环往复。接收方向则依赖交换机把包分散到各个端口。它的优点是配置极简，系统侧几乎不用额外参数，理论上能把多块网卡的发送带宽叠加起来。

但它的坑也很典型。乱序问题：同一个TCP连接的不同数据包可能从不同物理网卡发出，到达对端的时间差会导致乱序，接收端要重排，重排就要消耗CPU，严重时吞吐不升反降。交换机要求：交换机侧必须把连到这台机器的多个端口配置成聚合组（静态聚合，不跑协商协议），否则交换机会认为同一个MAC地址出现在多个端口上，触发MAC漂移告警，甚至直接阻断。对端配合：如果对端也是服务器且没做类似配置，效果同样打折。

我一般只在两种情况下考虑mode 0：一是内网大流量传输场景，且两端都能控制、交换机可以配静态聚合；二是做压力测试时临时叠加带宽。生产环境里对延迟敏感的业务，我不太推荐它。

2.2 mode 1：主备模式，最省心的保底方案

mode 1叫active-backup，逻辑最干净：同一时刻只有一块网卡处于active状态，其余都是backup。active那块坏了，驱动在毫秒级把流量切到backup上。发送只走active，接收也只走active，所以不存在乱序，也不需要交换机做任何聚合配置——交换机看到的就是多个独立端口，只是同一时间只有一个端口在收发包。

这个模式是我在绝大多数"只要求高可用、不追求带宽"场景下的默认选择。数据库主库、管理节点、跳板机这类机器，带宽需求不高但对连续性要求极高，mode 1的简单可靠就是最大优势。它的代价是带宽利用率低，N块网卡只用到1块的带宽，其余都在待命。

配置上有个关键参数primary，用来指定优先使用哪块网卡。不指定的话驱动按加入顺序选，指定了可以让流量优先走性能更好或链路上更优的那块。另一个参数miimon（链路监测间隔，单位毫秒）必须配，否则驱动不知道链路什么时候断。我一般设100，即每100毫秒检测一次，兼顾灵敏度和开销。

# mode 1 典型配置片段（/etc/sysconfig/network-scripts/ifcfg-bond0 风格） BONDING_OPTS="mode=1 miimon=100 primary=eth0"

2.3 mode 2：异或哈希，静态均衡的折中

mode 2叫balance-xor，发送方向按源MAC、目的MAC做异或运算，把流量映射到某块成员网卡上。同一个"源-目的"组合始终走同一块网卡，所以单个连接不会乱序，这是它比mode 0聪明的地方。不同连接之间则被分散到不同网卡，实现一定程度的负载均衡。

它的局限在于均衡粒度是"连接"而不是"包"。如果业务是大量短连接，分散效果不错；如果业务是少数几个大连接（比如单个大文件传输、单条数据库长连接），那流量还是会集中到一块网卡上，其他网卡闲着。另外它和mode 0一样，需要交换机侧配置静态聚合组，否则MAC漂移问题照旧。

mode 2适合连接数多、单连接流量不大的场景，比如Web前端集群。选它之前先想清楚：你的流量是"很多小水管"还是"几根大水管"？前者适合，后者不适合。

2.4 mode 3：广播模式，容错但浪费

mode 3叫broadcast，工作方式是把每个包从所有成员网卡同时发出去。对端会收到多份相同的包，由上层协议去重。它的容错性极强——任何一块网卡活着，包就能到达，但代价是带宽成倍浪费，N块网卡发同一个包，有效吞吐还是1块的量。

这个模式在实际生产中用得很少，我见过的场景基本是特殊的老系统或特定硬件环境，需要极端的容错保证且不在乎带宽。它同样需要交换机侧做聚合配置，否则多端口收到同一MAC的包会出问题。除非你有非常明确的理由，否则不建议选它。

2.5 mode 4：动态链路聚合，标准化程度最高

mode 4叫802.3ad，也就是LACP（链路聚合控制协议）。这是七种模式里唯一一个"和交换机协商"的模式：系统和交换机之间周期性交换LACP报文，双方协商出哪些链路可以加入聚合组、哪些处于待命状态。协商成功后，流量按哈希分散到各条链路，某条链路故障时协议能感知并把它移出聚合组。

它的优点是标准化、可协商、故障感知准确，是数据中心里最"正规"的聚合方式。但要求也最硬：交换机必须配置LACP聚合组，且两端的聚合参数（速率、双工、聚合模式）要匹配。系统侧通常要配xmit_hash_policy（发送哈希策略），常见取值有layer2（按MAC哈希）、layer3+4（按IP和端口哈希）。后者均衡粒度更细，适合连接数多的场景。

# mode 4 典型配置 BONDING_OPTS="mode=4 miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"

lacp_rate=fast表示每1秒发一次LACP报文（slow是30秒），故障感知更快，代价是协议报文开销略增。我一般生产环境用fast，测试环境无所谓。

2.6 mode 5：自适应发送负载均衡，收方向仍是主备

mode 5叫balance-tlb（transmit load balancing），发送方向根据每块网卡的当前负载动态分配流量，接收方向则只有一块网卡在工作，其余待命。它不需要交换机做聚合配置，这是它相对mode 0/2/4的一大优势——交换机侧当普通独立端口处理即可。

它的均衡依据是"当前负载"，驱动会跟踪每块网卡的发送队列情况，把新流量往相对空闲的网卡上放。但接收方向没有负载均衡，所以整体吞吐受限于单块网卡的接收能力。另外它依赖网卡的发送队列状态，不同驱动的支持程度有差异，选之前最好确认网卡驱动是否完整支持。

mode 5适合"发送流量远大于接收流量"的场景，比如日志采集节点、备份源端。这类机器往外吐数据多，往里收数据少，发送侧的动态均衡能派上用场。

2.7 mode 6：自适应负载均衡，收发都均衡

mode 6叫balance-alb（adaptive load balancing），在mode 5的基础上增加了接收方向的负载均衡。它的做法是通过ARP协商：驱动修改发出的ARP响应，让不同对端把包发到不同的成员网卡上，从而实现接收侧的分散。发送侧则沿用mode 5的动态负载逻辑。

它同样不需要交换机做聚合配置，交换机看到的是多个独立端口。但ARP协商这套机制有前提：对端要在同一广播域内，且网络里不能有干扰ARP的中间设备。跨三层、跨VLAN的场景下，接收均衡效果会打折扣甚至失效。

mode 6是"不想动交换机、又想尽量均衡"时的常见选择，适合内网同网段、流量双向都较大的场景。但它的行为比mode 4"隐晦"，出问题时排查难度更高，因为均衡逻辑藏在驱动和ARP交互里，不像LACP那样有明确的协议状态可看。

2.8 七种模式速查对照

把上面的内容压缩成一张表，选型时先扫一眼。

3. 实操落地：从配置到验证的完整流程

3.1 配置前的环境确认清单

动手之前有几件事必须先确认，否则配到一半发现条件不满足，返工成本很高。第一，确认物理网卡数量和名称，用ip link或nmcli device status看清楚哪些网卡准备加入bond，确保它们当前没有被其他配置占用（比如已经配了IP、已经属于某个网桥）。第二，确认交换机侧的能力和配置权限，mode 0/2/3/4都需要交换机配合，如果交换机不归你管，先沟通清楚能不能配聚合组。第三，确认业务对中断的容忍度，配置bond过程中网络会短暂中断，生产环境要安排窗口。

第四，确认系统使用的网络管理工具。现在主流发行版分两派：传统network-scripts（ifcfg文件）和NetworkManager（nmcli命令）。两套工具的配置方式不同，混用容易出问题。我建议统一用一套，新系统优先用NetworkManager，老系统沿用ifcfg。第五，确认内核bonding模块可用，modinfo bonding能正常输出信息即可。

注意：如果物理网卡之前配过IP，加入bond前要把它们的IP配置清掉，否则可能出现bond0和成员网卡同时持有地址的混乱状态。成员网卡的配置文件里应该是BOOTPROTO=none、MASTER=bond0、SLAVE=yes这样的从属配置。

3.2 用nmcli配置bond的完整步骤

以mode 1为例，走一遍NetworkManager的配置流程。假设物理网卡是ens33和ens34，bond名称bond0，IP用静态地址。

# 1. 创建bond接口，指定模式 nmcli connection add type bond con-name bond0 ifname bond0 \ bond.options "mode=active-backup,miimon=100" # 2. 把两块物理网卡加入bond nmcli connection add type ethernet con-name bond0-slave1 ifname ens33 master bond0 nmcli connection add type ethernet con-name bond0-slave2 ifname ens34 master bond0 # 3. 给bond0配IP nmcli connection modify bond0 ipv4.addresses 192.168.10.50/24 nmcli connection modify bond0 ipv4.gateway 192.168.10.1 nmcli connection modify bond0 ipv4.dns 192.168.10.2 nmcli connection modify bond0 ipv4.method manual # 4. 启用连接 nmcli connection up bond0-slave1 nmcli connection up bond0-slave2 nmcli connection up bond0

这套命令的逻辑是：先建逻辑接口并定模式，再把物理接口挂上去当从属，最后给逻辑接口配地址。顺序不能乱，先配地址再挂从属容易出问题。mode 4的话，把bond.options改成mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4即可，其余步骤一样。

3.3 用ifcfg文件配置的对照写法

老系统上还是ifcfg文件更常见。bond0的配置文件大致如下。

# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none IPADDR=192.168.10.50 PREFIX=24 GATEWAY=192.168.10.1 BONDING_OPTS="mode=1 miimon=100 primary=ens33" ONBOOT=yes

成员网卡ens33的配置则是从属形态。

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

ens34照抄ens33，只改DEVICE。这里有个容易忽略的点：BONDING_OPTS里的参数顺序和拼写要准确，写错了驱动会静默忽略部分参数，表现为"配了但没生效"。改完配置后重启网络服务或重启对应连接，然后用下面的方法验证。

3.4 验证bond是否真正生效

配置完不能只看接口起来了就完事，要验证三件事：模式对不对、成员状态对不对、故障切换灵不灵。

# 查看bond当前模式和成员状态 cat /proc/net/bonding/bond0

这个文件是排查bond问题的第一现场，里面会显示Bonding Mode、当前active的网卡（Currently Active Slave）、每块成员网卡的MII Status（up/down）和链路状态。mode 1下应该看到一块active、一块backup；mode 4下应该看到LACP协商状态（LACP rate、Aggregator ID等）。

# 查看逻辑接口和成员接口状态 ip link show bond0 ip -br link show

故障切换验证是必做项。mode 1下，用ip link set ens33 down把主卡手动down掉，然后立刻cat /proc/net/bonding/bond0看active是否切到ens34，同时从另一台机器持续ping这个bond0的IP，观察丢包情况。正常情况下应该只丢一两个包甚至不丢。验证完记得把网卡up回来。

提示：故障切换验证一定要在业务上线前做，而且要两个方向都测——主卡down测切到备卡，备卡down测不影响主卡。我见过只测了一个方向，结果备卡本身有问题没发现，真出故障时切换失败。

3.5 交换机侧的配合要点

mode 0/2/3需要交换机把多个端口配成静态聚合组（不同厂商叫法不同，有的叫static trunk，有的叫port-channel），聚合模式选"静态"或"on"，不跑协商协议。mode 4需要配LACP聚合组，聚合模式选"active"或"dynamic"。两种配置的共同点是：聚合组内所有端口的速率、双工、VLAN配置必须一致，否则聚合起不来或行为异常。

这里有个高频坑：系统侧配了mode 4，交换机侧却配成了静态聚合，结果LACP报文发过去交换机不认，聚合组一直处于协商失败状态，流量只走其中一条链路甚至完全不通。排查时先看/proc/net/bonding/bond0里的LACP状态，再看交换机侧的聚合组状态，两边对不上就是配置不匹配。

4. 踩坑实录与排查速查

4.1 配了bond但带宽没叠加

这是最常见的预期落差。很多人以为配了bond带宽就自动翻倍，实际上要看模式和流量特征。mode 1/3/5的接收方向、mode 1的发送方向都只用单卡，带宽本来就不会叠加。mode 0/2/4/6虽然做了分散，但分散粒度是"连接"或"哈希"，单个大连接仍然只走一块网卡。

判断方法：用多个并发连接做传输测试（比如多个scp或iperf3 -P 4），看总吞吐是否接近N倍单卡带宽。如果多连接能叠加、单连接不能，说明配置没问题，是流量特征决定的。如果多连接也不叠加，再查哈希策略和交换机聚合组。

4.2 切换不灵敏或切换后不通

切换不灵敏，先查miimon有没有配、值是不是太大。没配miimon的话驱动可能依赖其他监测机制，行为不确定。切换后不通，常见原因是备卡本身链路有问题（网线松、交换机端口down），或者切换后ARP表没更新导致对端还往旧MAC发。后者可以调小arp_interval和arp_ip_target让驱动主动发ARP更新，但会增加开销，非必要不用。

还有一种情况是切换后IP冲突或路由异常，这通常是成员网卡上残留了旧配置。检查成员网卡的ifcfg文件，确保只有MASTER/SLAVE从属配置，没有IPADDR。

4.3 mode 4协商失败的排查顺序

LACP协商失败按这个顺序查：第一步看系统侧/proc/net/bonding/bond0，确认模式是802.3ad、LACP rate符合预期；第二步看交换机侧聚合组状态，确认端口已加入聚合组且协议状态是up；第三步核对两端参数，速率双工是否一致、聚合模式是否都是LACP；第四步看物理链路，光模块、网线、端口有没有告警。这四步走完基本能定位。

4.4 常见问题速查表

4.5 几条不写在文档里的经验

第一，新环境优先用mode 1打底。先把高可用跑通、验证切换正常，再根据带宽需求考虑升级到mode 4。一上来就上复杂模式，出问题时变量太多不好定位。第二，成员网卡的驱动版本要一致，混用不同版本驱动在mode 5/6下可能出现负载统计不一致，导致均衡行为怪异。第三，bond0的MTU要和成员网卡一致，不一致时大包会被丢弃，表现为"小包通、大包不通"，这个现象很容易误判成路由问题。

第四，改bond配置前先备份原配置，尤其是生产环境。bond配置改错导致失联的情况我见过不止一次，有备份至少能快速回滚。第五，监控要覆盖bond状态，把/proc/net/bonding/bond0里的active slave和MII Status纳入监控，切换事件要能告警，否则备卡悄悄坏了你都不知道，等主卡也坏了才发现已经裸奔很久。

我个人在实际操作中的体会是，bond这七种模式没有绝对的好坏，只有匹配不匹配。把"我要高可用还是要带宽"这个问题先答清楚，再对照交换机能力和流量特征去选，基本不会走偏。配置本身十几行命令的事，真正花时间的是验证和排查——切换测没测、交换机对不对、监控有没有覆盖，这些才是决定这套bond能不能在关键时刻顶上的东西。