网卡做bond这件事我最早是在一台老旧的存储节点上接触的。当时两块网卡插在同一个交换机上配了主备模式结果交换机做维护重启整个链路直接断了——因为两块网卡都连在同一台设备上主备切换等于没切。那次之后我才认真把Linux bonding的七种模式挨个啃了一遍也踩了不少配置层面的坑。bond链路聚合本质上是把多块物理网卡在系统层面虚拟成一块逻辑网卡对外只暴露一个接口对内负责流量的分发与冗余。它解决的核心问题就两个一是带宽不够用单口千兆跑满也就125MB/s多口聚合能往上叠二是单点故障一块网卡或一根线挂了业务不中断。这套东西适合谁看做服务器运维的、搞虚拟化平台的、搭存储集群的以及任何需要在Linux上把网络做得更结实的同学。下面我按模式逐个拆把每个模式到底怎么工作、什么场景该选它、配置时哪里容易翻车全部摊开讲。1. 先搞清楚bond的底层骨架再谈模式很多人一上来就背七种模式的名字背完还是不知道该选哪个。问题出在没理解bond的底层是怎么把包发出去的。bond驱动在逻辑上分两层上层是bonding核心负责维护一个“从设备列表”决定当前哪些物理网卡是活跃的下层是每个从设备自己的发送队列。真正决定流量怎么走的是发送哈希策略和故障切换逻辑这两件事的组合。七种模式说白了就是这两件事的不同排列组合。1.1 从设备状态机与主备选举bond驱动给每个从设备维护一个状态核心是BOND_STATE_ACTIVE和BOND_STATE_BACKUP。在主备类模式mode 1、mode 3里同一时刻只有一个设备处于ACTIVE其余都是BACKUP。主设备的选举不是靠“谁先起来谁当主”这么随意而是有一套基于bond_curr_active_slave指针的切换逻辑当当前主设备被判定为失效链路down、对端不响应ARP等驱动会遍历从设备列表按顺序挑下一个可用的顶上。这里有个细节值得注意——切换顺序默认是按网卡加入bond的顺序也就是enslave的先后。如果你希望某块网卡优先做主得在配置里显式指定primary参数否则顺序可能和你预期相反。1.2 发送路径上的哈希与分发在负载均衡类模式mode 0、2、4、5、6里多个从设备同时处于ACTIVE包往哪块网卡发取决于哈希函数。bond支持几种哈希策略基于源MAC、基于目的MAC、基于源目的MAC的异或、基于IP地址的异或、基于TCP/UDP端口号的哈希等。以最常用的layer34xmit_hash_policylayer34为例它会把源IP、目的IP、源端口、目的端口一起算进哈希这样同一条TCP连接的所有包会固定走同一块网卡避免乱序。而layer2策略只看MAC粒度粗但兼容性最好。哈希策略选错是负载不均的头号原因后面讲mode 4的时候会重点说。1.3 miimon与ARP监测故障判定的两条路bond判断链路是否健康主要靠两种机制。miimon是MII监控驱动周期性读取网卡的MII寄存器看物理链路层是否up单位是毫秒常用值100。它反应快但只能看到“线插没插、对端电口亮不亮”看不到对端交换机端口是否真的在转发。arp_interval是ARP监测周期性向指定的arp_ip_target发ARP请求收到回复才算健康能穿透到三层但配置稍复杂且目标IP必须可达。实际生产里我一般用miimon100打底关键链路再叠加ARP监测做双保险。这里有个坑miimon设太小比如10会导致频繁检测CPU占用上升设太大比如1000则故障发现慢切换延迟高100ms是个比较稳的折中。2. mode 0与mode 2把带宽叠起来的两种思路这两个模式都属于“多活”类型所有从设备同时工作目标都是提升吞吐。但它们的实现路径完全不同适用场景也差得远。很多人以为mode 0就是简单的“轮流发包”其实它内部还有一层基于哈希的分发逻辑而mode 2干脆不做哈希直接按包轮询。理解这两者的差异是选对模式的第一步。2.1 mode 0balance-rr轮询分发的利与弊mode 0叫平衡轮询工作方式很直白发第一个包走第一块网卡第二个包走第二块第三个包走第三块循环往复。它不需要交换机做任何特殊配置普通交换机就能跑这是它最大的优点。但问题也在这里——同一个TCP连接的不同包会被打散到不同物理链路上。如果两条链路的延迟有细微差异哪怕差零点几毫秒包到达对端的顺序就可能乱掉接收端TCP栈要做重排重排缓冲区一满就触发重传吞吐反而下降。我实测过在两条直连链路上跑mode 0单流大文件传输的吞吐还不如单块网卡就是因为乱序。所以mode 0的正确用法是多流并发场景比如多台客户端同时访问一台服务器每条流各自走一块网卡整体带宽能叠起来。单流场景别碰它。配置上mode 0的典型写法是在bond配置文件里指定# /etc/sysconfig/network-scripts/ifcfg-bond0 片段 BONDING_OPTSmode0 miimon100 xmit_hash_policylayer2xmit_hash_policy在mode 0下其实影响有限因为轮询本身就不看哈希但设成layer2能保证同一对MAC之间的流量尽量走同一块网卡减少乱序概率。这是个容易被忽略的细节。2.2 mode 2balance-xor用哈希换稳定mode 2在mode 0的基础上加了一层哈希不是简单轮询而是根据源MAC、目的MAC做异或运算算出一个值来决定走哪块网卡。这样同一对通信双方的所有包会固定走同一条链路彻底避免了乱序问题。代价是负载均衡的粒度变粗了——如果只有一对通信双方那所有流量还是压在一块网卡上另一块闲着。所以mode 2适合“通信对端数量较多且相对均匀”的场景比如一台服务器同时服务几十个客户端哈希能把不同客户端分散到不同网卡。这里有个实操经验mode 2的哈希默认是layer2基于MAC如果你的环境里客户端MAC分布不均匀比如经过某些网关后MAC被改写哈希效果会大打折扣。这时候可以改成layer34用IP和端口做哈希粒度更细。但要注意改了哈希策略之后已经建立的连接不会重新分布新连接才会按新策略走所以改完得等老连接自然老化或者干脆重启服务。2.3 两种模式的选型对照对比项mode 0balance-rrmode 2balance-xor分发方式逐包轮询哈希选路单流乱序风险高低交换机要求无特殊要求无特殊要求适合场景多流并发、对乱序不敏感多客户端、需稳定单流带宽叠加效果多流下明显取决于哈希分布我个人的判断标准很简单如果业务是单条大流比如备份、视频推流选mode 2如果是多客户端并发访问比如Web集群mode 0和mode 2都能用但mode 2更省心。mode 0那种逐包轮询的野路子现在新环境里我基本不用了乱序带来的隐性成本太高。3. mode 1与mode 3冗余优先的两种兜底方案主备模式的思路和负载均衡完全相反同一时刻只有一块网卡干活另一块待命。它的价值不在带宽而在“网卡或链路挂了业务不中断”。mode 1和mode 3都属于这一类但故障判定的严格程度不同选哪个取决于你对“故障”的定义有多苛刻。3.1 mode 1active-backup最朴素也最可靠的主备mode 1是七种模式里配置最简单、兼容性最好的。一块网卡ACTIVE其余BACKUPACTIVE挂了驱动立刻切到BACKUP。它不需要交换机做任何聚合配置两块网卡甚至可以插在不同交换机上——这正是它最大的价值跨设备冗余。前面开头我提到的那个存储节点事故如果当时用的是mode 1且两块网卡分插两台交换机交换机重启就不会导致断链。所以做高可用的时候mode 1配跨交换机是我最推荐的组合。配置要点BONDING_OPTSmode1 miimon100 primaryens33primaryens33指定ens33优先做ACTIVE这样正常情况下流量走ens33切换行为可预期。如果不指定驱动按加入顺序选顺序一变主备就跟着变排查问题时容易懵。另外mode 1下xmit_hash_policy无效因为只有一个口在发设了也没用。3.2 mode 3broadcast所有口同时发最暴力mode 3叫广播模式所有从设备同时发送每一个包。听起来很浪费带宽但它解决了一个特殊问题对端需要从多条路径同时收到相同数据。典型场景是某些容错系统要求数据在两条独立链路上同时到达任何一条断了另一条还能用且不需要切换时间。它的代价是带宽利用率只有1/NN为网卡数因为每个包都复制了N份。mode 3在实际生产里用得很少我只在个别工业控制场景见过——那种场景对切换延迟零容忍宁可浪费带宽也要保证“永远有路”。配置上和mode 1类似但不需要primary参数因为所有口都在发。注意mode 3对交换机有要求如果两块网卡接同一台交换机交换机会收到重复包可能触发MAC地址漂移告警所以务必分接不同交换机或做端口隔离。3.3 主备模式的切换延迟实测切换延迟是主备模式的核心指标。我用miimon100实测过mode 1的切换从拔线到流量恢复大约在150~250ms之间取决于TCP重传的时机。如果业务对这点延迟敏感比如数据库心跳可以把miimon调到50切换能压到100ms左右但检测开销翻倍。还有个技巧开启fail_over_macactive让bond在切换时主动发免费ARP通告新MAC避免对端ARP缓存过期导致的额外延迟。这个参数在跨交换机场景下尤其有用默认是none很多人不知道要改。4. mode 4802.3ad动态聚合的正统玩法mode 4是唯一一个需要交换机配合的模式也是企业环境里最“正规”的聚合方式。它基于IEEE 802.3ad标准通过LACP链路聚合控制协议和交换机协商动态管理聚合组成员。和前面几种模式比它的优势在于交换机知道哪些口是一个聚合组能协同做负载均衡和故障切换而不是靠服务器单方面猜。4.1 LACP协商过程与聚合组建立mode 4启动后bond驱动会在每块从设备上发LACPDULACP数据单元交换机收到后回应双方协商出一个聚合组aggregator。协商内容包括系统优先级、端口优先级、端口状态等。只有协商成功的端口才能进入转发状态。这个过程有个细节LACP有超时机制短超时fast是1秒长超时slow是30秒通过lacp_ratefast可以设成短超时故障发现更快。默认是slow很多环境切换慢就是因为这个没改。配置示例BONDING_OPTSmode4 miimon100 lacp_ratefast xmit_hash_policylayer34交换机侧需要把对应端口配成LACP主动模式active或被动模式passive并加入同一个聚合组。两边模式要匹配一边active一边passive可以两边都passive则协商不起来——这是最常见的配置错误之一。4.2 xmit_hash_policy在mode 4下的关键作用mode 4的负载均衡完全依赖哈希策略选错策略会导致“聚合了但流量全压一个口”。默认策略是layer2只看MAC在虚拟化环境里问题很大——虚拟机的MAC往往集中在少数几个前缀哈希分布极不均匀。我一般直接上layer34把IP和端口都算进去分布明显改善。但layer34有个限制它要求所有从设备的链路速率一致否则哈希可能把流量分到慢速口上。如果环境里混了千兆和万兆得用layer23或者干脆统一速率。还有个坑某些老交换机的LACP实现不支持layer34的哈希结果会出现“服务器认为走了两个口交换机只从一个口回包”的现象表现为上行带宽叠了、下行没叠。排查时用cat /proc/net/bonding/bond0看每个口的收发包计数如果发送计数均匀但接收计数一边倒基本就是哈希策略和交换机不匹配换回layer2试试。4.3 mode 4的故障切换与LACP超时联动mode 4的切换依赖LACP协商状态。当某个口的LACPDU超时未收到回应该口被移出聚合组流量重新哈希到剩余口。切换速度和lacp_rate直接相关slow模式下最长要30秒才发现fast模式1秒。所以生产环境务必设lacp_ratefast否则一次交换机端口故障可能造成半分钟的业务抖动。另外miimon在mode 4下仍然有效它做物理层检测和LACP的三层协商形成互补两个都开着更稳。5. mode 5与mode 6不用交换机配合的“伪聚合”这两个模式比较特殊它们能在普通交换机上实现类似负载均衡的效果不需要交换机做任何聚合配置。原理是发送时按哈希分散到多块网卡接收时所有网卡都收但只有一块网卡真正把包交给上层其余网卡的包被丢弃。这种“发多收一”的机制决定了它们的适用边界——主要优化发送方向的带宽接收方向还是单口速率。5.1 mode 5balance-tlb发送负载均衡mode 5叫自适应发送负载均衡。它根据每块网卡的当前发送负载动态分配流量负载低的口多分点负载高的少分点。接收方向靠ARP协商bond定期向对端发ARP对端回应时记录下从哪个口来的后续回包就走那个口。所以接收方向是“选定一个口”不是聚合。这个模式适合发送流量远大于接收流量的场景比如视频推流服务器、日志采集节点。配置上要注意tlb_dynamic_lb1默认开启让动态负载均衡生效。如果关掉就退化成简单的哈希分发。另外mode 5对网卡驱动有要求不是所有驱动都支持ethtool的发送队列查询老网卡可能跑不起来配之前先用ethtool -S确认驱动支持。5.2 mode 6balance-alb收发都兼顾的折中mode 6在mode 5的基础上加了接收负载均衡RLB。它通过ARP协商让不同的对端把回包发到不同的本地网卡上——具体做法是bond修改发出的ARP请求的源MAC让对端以为不同网卡有不同的MAC从而把回包分散。这样接收方向也能利用多块网卡了。但RLB有个硬限制它依赖对端的ARP缓存行为如果中间有路由器或网关改写了MACRLB就失效。所以mode 6只在“服务器和对端在同一二层网络”时有效跨三层就退化成mode 5的效果。还有个常见误解mode 6不需要交换机配置但它对交换机有隐性要求——交换机必须允许同一个IP对应多个MAC因为bond在ARP里用了不同源MAC。有些交换机的端口安全策略会拦截这种“MAC漂移”表现为间歇性丢包。遇到这种情况要么关掉端口安全要么退回mode 1。5.3 五种“免交换机配置”模式的横向对比模式发送分发接收利用交换机要求典型场景mode 0轮询单口无多流并发mode 1单口单口无跨设备冗余mode 2哈希单口无多客户端mode 5动态负载单口ARP选定无发送密集型mode 6动态负载多口ARP分散允许MAC漂移同二层收发均衡这张表是我排查问题时最常翻的选型时先看“交换机能不能配”不能配就在这五个里挑能配就直接上mode 4别折腾。6. 配置落地时那些文档不会写的坑模式讲完了真正让人头大的是配置过程中的细节。bond的配置文件在不同发行版里位置和字段都不一样参数之间还有隐含依赖稍不注意就是“配了但不生效”。这一节我把踩过的坑按出现频率排一排。6.1 配置文件字段的优先级与覆盖关系bond的参数可以在三个地方设/etc/sysconfig/network-scripts/ifcfg-bond0里的BONDING_OPTS、/etc/modprobe.d/bonding.conf里的模块参数、以及运行时通过sysfs写入。优先级是运行时 配置文件 模块参数。很多人改了ifcfg文件重启网络服务不生效就是因为模块参数里写死了旧值把配置文件覆盖了。排查时先看cat /proc/net/bonding/bond0里的实际生效值再回头找哪里设的。还有个坑BONDING_OPTS里的参数用空格分隔不能有换行写长了容易断行导致解析失败。我一般写成一行或者用反斜杠续行但确保续行符后面没有空格。6.2 从设备加入bond的顺序问题enslave的顺序影响主备选举和哈希分布。在ifcfg体系里从设备的MASTERbond0和SLAVEyes决定加入关系但加入顺序取决于网络服务启动时扫描配置文件的顺序不完全可控。如果业务依赖特定网卡做主务必用primary参数显式指定别赌顺序。另外从设备配置文件里不要设IP设了会和bond0的IP冲突表现为“能ping通但业务不通”的怪现象。6.3 切换后ARP缓存与对端感知延迟主备切换后新ACTIVE网卡的MAC和对端交换机MAC表需要更新。如果对端ARP缓存里还是旧MAC回包会发到已经down的口上丢包直到缓存老化。解决办法是切换时主动发免费ARPgratuitous ARP。bond驱动在mode 1下默认会发但如果fail_over_mac设成none发的ARP用的还是bond0的MAC对端可能不更新。设成fail_over_macactive能让bond用新口的MAC发ARP强制对端更新。这个参数在跨交换机主备场景下是必调的文档里往往一笔带过。6.4 虚拟化环境下的bond特殊处理在KVM或容器环境里做bond有个额外问题虚拟网卡的MAC是随机生成的哈希策略基于MAC时分布极不均匀。这时候要么把虚拟网卡MAC固定成有规律的地址要么直接用layer34哈希。另外虚拟交换机如Linux bridge对bond的支持有限mode 4在bridge上可能协商不起来得用Open vSwitch或者直通物理口。我见过在bridge上硬配mode 4折腾一下午没通的案例最后换成mode 1五分钟搞定——虚拟化环境优先考虑mode 1别跟mode 4死磕。7. 监控与排错从/proc里读出真相bond配好只是开始日常运维得能看懂它的状态。/proc/net/bonding/bond0是信息最全的地方但字段多新手容易看晕。我按排查顺序把关键字段捋一遍。7.1 读懂/proc/net/bonding的输出输出分几块Bonding Mode、MII Status、每个slave的详细信息。重点看三个地方MII Status整体链路状态up还是down、Slave Interface下每个口的MII Status和Speed/Duplex、以及Slave queue IDmode 4下看聚合组分配。如果整体MII Status是up但业务不通往下看每个口的收发包计数——cat /sys/class/net/bond0/statistics/tx_packets和每个slave的对应计数对比能看出流量是否真的分散了。7.2 常见故障的排查链路我整理了一个排查顺序基本能覆盖八成问题先看bond0本身up没upip link show bond0如果state DOWN检查是否有slave成功加入。再看slave是否enslavedcat /proc/net/bonding/bond0里有没有列出所有预期网卡缺了就是配置文件没生效。然后看MII Status某个slave显示down物理层问题查线、查交换机端口。最后看流量分布ip -s link show bond0和各slave的计数分布不均就是哈希策略问题。这个顺序的逻辑是“从整体到局部、从配置到物理”避免一上来就钻细节。7.3 用ethtool和ip命令做交叉验证ethtool bond0能看bond0的链路速率通常是所有slave里最低的那个ethtool ens33看单口速率。如果bond0显示的速率和预期不符说明有慢速口拖后腿。ip -s link看错误计数RX errors或TX errors持续增长往往是双工不匹配或线缆质量问题。我遇到过一次mode 4下行带宽上不去最后查出来是一根网线老化导致CRC错误交换机把那个口踢出了聚合组/proc里看slave少了一个才发现。8. 选型决策什么场景该用哪个模式讲了这么多模式最后落到“怎么选”。我的经验是先问三个问题交换机能不能配聚合业务是单流还是多流要不要跨设备冗余三个问题的答案基本能锁定模式。8.1 按交换机能力分流如果交换机支持LACP且愿意配直接mode 4这是性能和可维护性最好的方案。如果交换机不能配比如托管在别人机房、或者用的是不可管理的交换机那就在mode 0/1/2/5/6里选。其中mode 1适合冗余优先mode 2适合多客户端mode 5/6适合发送密集且同二层。8.2 按业务流量特征微调单流大带宽备份、迁移选mode 2或mode 4配layer34多客户端并发选mode 0或mode 2发送远大于接收推流、采集选mode 5同二层且收发都要均衡选mode 6。别为了“看起来高级”硬上mode 4交换机不配合的话它还不如mode 1稳。8.3 一个真实环境的选型复盘之前给一个内部文件服务做网络改造场景是几十个客户端并发读写交换机是可管理的但运维不愿意改配置。我最初想上mode 4沟通成本太高退而求其次选了mode 2配layer34哈希。实测下来客户端数量多的时候带宽能叠到接近双口线速单客户端大文件传输走单口但稳定不乱序。后来加了一块网卡做三口的mode 2哈希分布依然均匀。这个案例说明在交换机不可控的约束下mode 2是被低估的选项它比mode 0稳比mode 4省事适合大多数“想叠带宽又不想动交换机”的场景。8.4 参数配置的通用模板最后给一份我常用的配置模板覆盖大部分场景改改模式号就能用# /etc/modprobe.d/bonding.conf alias bond0 bonding options bonding mode2 miimon100 xmit_hash_policylayer34 # /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOnone IPADDR192.168.1.10 PREFIX24 BONDING_OPTSmode2 miimon100 xmit_hash_policylayer34 # 从设备 ifcfg-ens33 / ifcfg-ens34 DEVICEens33 MASTERbond0 SLAVEyes BOOTPROTOnone改完执行systemctl restart network或nmcli connection reload然后用cat /proc/net/bonding/bond0确认模式、slave列表、MII状态都对。每次改完bond配置务必做一次拔线测试验证切换是否按预期发生、业务是否真的不中断——配置看着对和实际能切换是两码事这个测试花五分钟能省掉半夜被叫起来的麻烦。我个人在这些年的操作里体会最深的一点是bond的七种模式没有绝对的好坏只有匹配不匹配。很多人纠结“哪个模式性能最好”其实性能最好的mode 4在交换机不配合时寸步难行而看起来朴素的mode 1在跨设备冗余场景下无可替代。把每个模式的发送路径和故障逻辑想清楚选型就是水到渠成的事。另外任何bond配置上线前拔线测试和流量分布检查这两步别省它们比任何文档都更能告诉你真相。