如果你管过几台物理服务器大概率碰到过这种场景半夜监控突然报警某台机器的网卡挂了业务直接断掉你只能顶着黑眼圈跑机房换卡。Linux网卡bond就是解决这类问题的方案它允许把多块物理网卡绑定成一个逻辑网卡在链路层面做冗余或带宽聚合。而bond的7种模式就是决定这些物理网卡之间如何分工的7套策略。这篇文章我会把这些模式逐一讲透包括原理、适用场景、配置方法以及实际运维中常见的坑适合刚接触Linux网络、或者已经会用bond但想搞清楚底层逻辑的运维和开发同学。1. 为什么需要bond以及7种模式到底在解决什么问题1.1 单网卡等于单点故障普通服务器默认只有一块物理网卡在工作虽然现在板载网卡质量都不差但整条链路里任何一个环节出问题——网线松动、交换机端口down、光模块老化、网卡驱动异常——都会让业务瞬间不可用。更麻烦的是这种故障通常不会提前通知你而是发生在凌晨三点等监控报警时业务已经中断一段时间了。Linux的bond机制本质上就是内核里的网络 bonding 模块把两块或以上物理网卡组合成一个逻辑接口bond0。上层应用看到的只有一个IP底层数据却由多块物理网卡协同收发。一块网卡故障时另一块能顶上在部分模式下还能同时提升总吞吐。这个概念本身不难难的是搞清楚7种mode之间的差异因为每种mode对应完全不同的链路策略在故障切换和负载均衡上的表现天差地别。所以我会先给你一张速览表让心里有个框架然后再逐个拆细节。后面配置时你会频繁看到mode4、miimon这类参数理解了每个模式你才算真正掌握了bond。1.2 七种模式速览先记住这张表模式名称是否需交换机配合主要特点mode 0balance-rr建议静态聚合轮询发包每包轮流走不同网卡实现简单但可能乱序mode 1active-backup无需配置主备模式同一时刻单卡工作高可用首选mode 2balance-xor需要静态聚合按哈希分流同一条流固定走同一网卡避免乱序mode 3broadcast建议聚合所有包从所有网卡发出用重复帧换高可靠mode 4802.3ad需要LACP动态协商聚合数据中心主流方案mode 5balance-tlb无需配置发送负载均衡接收只靠主网卡mode 6balance-alb无需配置发送接收负载均衡通过ARP改写实现模式后面的数字就是BONDING_OPTS里mode的值内核实际对应一个枚举。你可以通过 /sys/class/net/bond0/bonding/mode 查看当前模式数值。有一个判断方法比死记硬背有用只要发送的数据会出现“同一MAC从多个端口发出”交换机就必须先做好聚合否则它会学MAC学到乱导致丢包甚至广播风暴。这个思路贯穿后面所有模式的理解。2. 七种模式逐个拆解原理、适用场景和踩坑点2.1 mode 0 balance-rr简单的轮询但坑最多mode0 名叫balance-rr也就是round robin。它发送数据包时不分连接也不看IP就是一个接一个轮流从eth0、eth1、eth2发出去。比如两个slave第一个包从eth0发出第二个包从eth1发出第三个包又回到eth0如此循环。这个机制在CPU看来很简单驱动层面的负载也最平均但实际问题不少。第一同一个TCP连接的连续数据包可能被拆到不同物理网卡上到达对端的顺序就可能被打乱。TCP虽然能处理乱序但代价是触发大量重复ACK和重传尤其是小包高并发场景整体吞吐反而会下降。第二mode0并非不需要交换机配置。因为两块网卡的MAC并不一样交换机从两个端口看到同一个IP对应的多个MAC。如果交换机端口没有做静态链路聚合它会在两个端口之间反复更新MAC表导致对端回包不稳定甚至把流量广播到整个二层域。所以mode0其实也要求交换机支持静态聚合并需要把对应端口手工捆绑成聚合口。真正适合mode0的场景其实很窄一般只在短距离、流量模型简单、链路质量极好的内网传输里能用。我不太建议新项目用mode0除非你明确知道自己在干什么并且愿意接受乱序和交换机配合带来的额外风险。2.2 mode 1 active-backup主备默认配置里的常青树mode1 是最直观、也最稳妥的模式。它同一时刻只会启用一块物理网卡剩余网卡都是后备状态。当主网卡出现链路down或驱动错误时bond会立刻把后备网卡切换为active对外IP保持不变。由于同一时刻只有一个MAC在工作交换机不需要做任何聚合配置接入层交换机直接把它当成普通网口就行。正因为这个特性mode1非常适合那些“只求不死、不求更快”的场景服务器管理口、数据库主控节点、Kubernetes控制平面的网络通道。带宽不会因为bond变大但故障切换的可靠性很实在。切换速度主要由检测方式决定。默认用miimon100也就是每100毫秒检查一次物理链路状态。如果你把miimon从100改成1000切换时间可能就会被拉长到秒级踩过坑的人都懂。有人还会在mode1里设置primaryeth0让系统启动后优先使用eth0只有当eth0挂了才切换eth1。这个参数在日常运维中很有用比如你想让流量务必走更高带宽的物理口而把另一块低带宽口当冷备。但要记住primary只是“优先偏好”不代表eth0恢复后立即抢占流量具体还要看updelay参数这个后面配置部分会提到。2.3 mode 2 balance-xor基于哈希的静态负载均衡mode2 的思路是给每个待发送的包算一个哈希值用哈希结果决定走哪块网卡。默认的xmit_hash_policylayer2也就是根据以太网头里的源MAC和目的MAC计算哈希。这样同一个目的MAC的连续数据包大概率会走同一块网卡避免了mode0那种瞬时乱序问题。但哈希不是万能的。如果二层流量高度集中比如所有请求都发给一台默认网关那么所有包的“目的MAC”都是网关的MAC哈希结果可能都落在同一块slave上负载均衡直接失效。这时候可以切换为xmit_hash_policylayer34把源/目的IP和端口也纳入哈希计算分布会均匀很多。mode2 同样要求交换机做静态聚合配置。因为多个slave对应同一个bond口交换机必须把这些端口捆绑成一个逻辑接口否则MAC地址学习会乱。很多傻瓜交换机虽然支持所谓的“链路聚合”但只支持LACP动态协商不支持静态手工聚合那mode2就跑不起来。这是我在实际项目里反复确认过的点。如果交换机能做静态聚合但暂时不想开LACP同时又有大量长连接并发流量mode2可以作为一种替代方案。不过从长期运维角度讲能被LACP替代的静态聚合我都建议优先上LACP。2.4 mode 3 broadcast广播模式重复帧换确定性mode3 是存在感最低的模式但它有一个非常明确的价值确定性。它会把每一个待发送的数据包复制到所有slave网卡上同时发出去。也就是说两块网卡同时发相同的内容接收端会收到两份一样的帧由上层协议栈或交换机去做去重。这个机制在普通服务器上确实少见但某些网络设备之间的互联链路比如VRRP心跳、路由协议的Hello报文反而希望能用这种方式保证单条链路断开时另一条链路立刻顶上不需要任何切换时间。代价也直白所有链路都在重复发送有效带宽没有任何提升纯粹是用带宽换可靠性。如果你跑的是正常的HTTP、数据库业务别选mode3除非你们测试过极端掉线场景确认业务协议能正确处理重复帧。交换机对重复帧的态度也要注意如果交换机没有把多个端口聚合它看到同一个源MAC从不同端口进来会以为发生了环路触发STP阻塞甚至丢包。所以mode3在交换机侧仍然建议把端口聚合起来让交换机把这个bond口当成一个逻辑端口看待。2.5 mode 4 802.3adLACP动态聚合数据中心的正解mode4 是我在正式环境里用得最多的一种模式理由很简单它用标准协议解决了mode0和mode2的静态配置问题。服务器和交换机之间通过LACP报文互相协商只有两端都确认端口能加入聚合组流量才会真正通过聚合口转发。这样即使有人误插了网线、交换配置错了LACP也会拒绝把不匹配的端口纳入聚合组安全性高很多。使用mode4时交换机的聚合口要配置成active或passive模式常见做法是配置类似Port Channel mode active的命令。服务器端BONDING_OPTS写 mode4 miimon100 xmit_hash_policylayer34 lacp_ratefast。注意xmit_hash_policy同样重要它决定了服务器发出的流量如何分摊到多块网卡。交换机侧也有自己的哈希策略虽然不要求一模一样但如果两边差异太大流量分布可能不理想。还有很多人对mode4有一个误解mode4不是让单条TCP流突破单网卡带宽。它做的是把多条不同连接分散到多块物理网卡上。比如你的业务有一堆并发连接通过哈希分布后总吞吐可以接近多块网卡之和但如果只有一条TCP连接它还是只能走一块物理网卡。因此大流量应用的瓶颈往往还在应用层并发而不是bond模式本身。2.6 mode 5 balance-tlb 和 mode 6 balance-alb自适应负载均衡交换机不配合时的妥协方案mode5 是发送端的自适应负载均衡。bond会根据每块slave的实时负载情况动态选择发送网卡避免像mode0那样固定轮询。它的好处是不需要交换机做聚合配置因为从交换机视角看这个bond只暴露一个主网卡的MAC。但缺陷也很明显接收流量全部落在主网卡上如果业务下载量大、回包大主网卡会成为瓶颈。mode6 则试图解决接收侧的问题。它在mode5的基础上通过ARP请求和应答的改写主动告诉对端这个IP可能从另一个MAC或端口出来从而让对端把不同连接的接收流量分到不同slave网卡上。这个机制在实现上做了不少“欺骗”工作效果能有但代价是CPU开销增加且在某些接入交换机开了端口安全限制MAC学习数量的环境里会直接踩雷。运维建议如果你的交换机不支持LACP但又想用多网卡提升吞吐mode6是可选方案之一但一定要在接入端口上关掉MAC地址数量限制并在测试环境验证ARP负载均衡是否真的生效。如果环境不允许动交换机干脆用mode1保命别为了带宽引入一个更复杂的故障源。3. 从零配置bond手把手实操3.1 配置前的硬件和内核检查开始配置之前先确认你手里到底有几块可用网卡。用ip link show正常能看到eth0、eth1等。如果网卡没有起来先检查网线或光模块别直接开始配置。接着确认内核是否加载bonding模块lsmod | grep bonding。如果没有先modprobe bonding再考虑做成系统启动自动加载。RedHat系一般在/etc/modules-load.d/bonding.conf里写bondingUbuntu系可以写到/etc/modules。还要注意网络管理方式。CentOS 7时代很多人默认用ifcfg文件配合network服务新版系统常常默认NetworkManager。两种方式都行但别混用。否则会出现一种诡异现象bond手工配置没问题重启后接口被NetworkManager接管从网卡变成了普通网卡。我见过不少这种案例最后都是把NetworkManager对相关接口的管辖关掉或者直接用nmcli配置。3.2 用ifcfg文件配置bond0RedHat系老手艺先创建/etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 TYPEBond BONDING_MASTERyes NAMEbond0 BOOTPROTOnone ONBOOTyes IPADDR192.168.10.5 PREFIX24 BONDING_OPTSmode4 miimon100 xmit_hash_policylayer34 lacp_ratefast然后是两个从网卡比如ifcfg-eth0DEVICEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyesifcfg-eth1也类似只是DEVICE改成eth1。这里最关键的一点从网卡上千万别配置IP地址和网关IP只在bond0上。如果你不小心把IP写在eth0上会看到路由表多出一个网段这种低级错误最容易在复制粘贴配置时发生。配置完成后重启network服务。如果用的是systemd系统记得先确认network服务是enabled状态否则执行完systemctl restart network后下次重启可能又回到空跑状态。重启完继续用ip link show bond0查看接口是否还存在再用cat /proc/net/bonding/bond0检查详细状态。如果你看到Bonding Mode显示为IEEE 802.3ad Dynamic link aggregation并且两块slave都是up说明起来了。如果slave的MII Status是DOWN先回头检查网线和交换机端口确认物理链路没问题再看交换机聚合口是否真的配置成功不要一上来就改bond参数。3.3 用nmcli配置bond新版系统的推荐姿势很多新系统默认跑NetworkManager这时候我更推荐用nmcli比写ifcfg文件清爽还不会出现服务抢占问题。核心命令如下nmcli connection add type bond ifname bond0 mode 4 \ ipv4.method manual ipv4.addresses 192.168.10.5/24 nmcli connection add type ethernet ifname eth0 master bond0 nmcli connection add type ethernet ifname eth1 master bond0 nmcli connection up bond0第一行创建了bond0指定mode是4。默认IP配置是DHCP要改成manual并指定IP。后面两行把两块物理网卡挂进去。创建完建议再用一条命令确认自动连接nmcli connection modify bond0 connection.autoconnect yes还有一个细节nmcli创建bond时如果直接给bond加上IPNetworkManager会自动生成bond-slave连接来绑定物理网卡。某些版本里mode4的高级参数比如xmit_hash_policy在nmcli里需要追加bond optionnmcli connection modify bond0 bond.options xmit_hash_policylayer34如果你不确定当前配置到底有没有生效就去翻/proc/net/bonding/bond0或者nmcli connection show bond0。命令记忆可以偷懒但验证环节不能偷懒。3.4 验证bond是否真的在干活配置bond不是看IP能通就行。我验证bond一般分三步看接口状态看流量分布看故障切换。第一步cat /proc/net/bonding/bond0。重点看Bonding Mode、MII Status、Slave Interface的MII Status。如果所有slave都是UP说明协议层面上没问题。第二步在业务流量跑起来后用下面这组命令对比每块网卡的收发字节数cat /sys/class/net/bond0/bonding/slaves ethtool -S eth0 | grep -E rx_bytes|tx_bytes ethtool -S eth1 | grep -E rx_bytes|tx_bytes对比两块网卡的字节数判断负载是否平均。mode4下一看便知如果两块卡流量差10倍以上大概率是哈希策略或者交换机聚合配置有问题。第三步验证切换。不要在虚拟机里直接拔网线测试虚拟网卡的link状态有时不可靠。更稳妥的方式是把slave接口手动down掉观察bond的切换行为ip link set dev eth0 down cat /proc/net/bonding/bond0看到eth0的MII Status变成DOWN同时eth1上升为active或者流量转移到eth1再ip link set dev eth0 up确认eth0恢复。我在生产环境上线前一定会做一次真实拔线演练包括拔物理网线、拔交换机端口模块都跑过一遍才敢收工。4. 模式选型和故障排查实录4.1 不同场景的选型建议很多新手会问是不是7种模式都试一遍选最好的真不是。可以参考这个思路场景推荐模式原因管理网段、控制节点mode1要求稳定不追求带宽切换可靠内网业务、交换机支持LACPmode4链路自动协商吞吐和冗余兼顾内网业务、交换机只支持静态聚合mode2按哈希分流避免乱序但需手工聚合交换机不支持任何聚合mode1或mode6mode1最稳mode6可尝试改带宽但慎用特殊广播/多播可靠性链路mode3用冗余帧换确定性简单内网大数据传输链路质量极好mode0分布均匀但要接受乱序风险选型时还要考虑未来维护交换机端口聚合需要额外配置mode4是协议协商人出错概率小。如果你公司网络团队配合能力一般我宁愿你选mode1也别硬上mode4。稳定压倒一切。4.2 模式与交换机配置的配合关系bond不是纯服务器端的事。只要从bond发出的帧出现同一MAC从多个物理端口出来或同一IP从不同MAC出来交换机的MAC学习就会混乱。所以模式选择直接决定交换端口要不要做聚合。我整理成一条通用规律需要交换机做聚合的模式有mode0、mode2、mode4其中mode4走LACP动态协商不需要交换机特殊配置的有mode1、mode5、mode6mode3视交换机而定建议也聚合。并不是说不需要交换机配置就代表它更高级而是它的工作方式天然避开了MAC漂移。这个规律在实际排障时很有用——看到bond模式先判断交换机侧有没有对应配置能省一半排查时间。4.3 常见故障bond起来了但流量不均衡这恐怕是bond上线后最容易被业务投诉的问题。明明两块网卡都是UP带宽却没有翻倍甚至不如单卡。原因通常有几种。第一哈希粒度太大。比如mode4用了默认的layer2所有流量都打向网关源MAC相同、目的MAC相同哈希结果会集中在同一块网卡上。解决方法是把xmit_hash_policy改成layer34加入IP和端口计算。第二交换机侧的哈希策略和服务器差异大。有些老交换机只支持基于源MAC的哈希和服务器基于IP端口的哈希不匹配。这种情况下两边要尽量换成都能支持的策略一般建议统一为基于IP和端口的哈希。第三业务本身并发连接数太少。mode4的吞吐提升依赖足够多的并发连接来均匀打满多块网卡。如果只有一个任务在拉取大文件那很可能一条流绑死在单卡上无法利用多卡带宽。这不算故障但需要跟业务方提前说清楚。排查时用ethtool -S eth0和eth1对比每块卡上的字节数别只看总带宽。我遇到过不少监控里看bond0总流量觉得没到预期一细看才发现根本是其中一块卡在裸奔。4.4 常见故障切换慢甚至切换后业务卡顿这个故障在mode1里特别典型。明明主卡断了备卡也切上去了业务还是卡了十几秒。原因一般有三个方向。第一MII检测参数太大。miimon默认100毫秒如果你手动改成1000甚至依赖系统默认值切换时间就会变长。建议保持100同时确认slave网卡的速率和双工模式设置正确否则链路检测可能不够灵敏。第二STP收敛。交换机端口从down到up要经过STP的listening和learning状态这过程默认几十秒对服务器的切换等待是致命的。如果交换机支持PortFast或edge port把连接服务器的端口配置为edge可以跳过STP等待。第三跨交换机bond的问题。如果两块slave分别接在不同的交换机上而两台交换机之间没有做堆叠或跨设备链路聚合当主链路断开后备链路所在交换机需要重新学习这个MAC的出口端口期间就可能产生丢包。要避免这个问题最简单的方法是让bond的两根网线插到同一台交换机或者插到已正确堆叠的交换机上。4.5 常见故障重启后bond没了或者变成普通网卡这个问题多发生在混合管理环境的机器上。常见原因有几个从网卡ONBOOTno导致启动时没挂进bondNetworkManager和network服务抢占接口udev规则给物理网卡改名导致ifcfg里的DEVICE对不上或者系统开启了网卡MAC随机化重启后从网卡MAC变化bond记录对不上。排查思路按顺序来先看bond0是否存在ip link show bond0。如果不存在说明内核模块没加载检查modprobe配置和/etc/modules-load.d。如果存在但没IP检查ifcfg-bond0是否被NetworkManager忽略或者NetworkManager是否抢占了从网卡。一般解决办法是对相关接口设置NM_CONTROLLEDno或者干脆用nmcli重新建一套bond连接让配置从同一个管理器里统一管理。还有一个容易忽略的点很多新系统对有线网卡默认不启用MAC随机化但个别发行版开着。如果从网卡的MAC在重启后和bond0的记录不一致bond可能起不来。可以在NetworkManager的网卡配置里把cloned-mac-address设为permanent固定网卡出厂MAC避免这种玄学故障。最后分享一点我的体会。bond这7种模式真正在生产环境频繁露脸的其实就mode1和mode4。别被数字吓到先把这两种吃透再根据实际网络环境去理解其他模式。我踩过的最大的坑就是在没有确认交换机是否支持LACP的情况下直接上了mode4结果流量全堆在一块网卡上。后来养成了一个习惯配置bond之前先问网络工程师三个问题——交换机能不能做聚合用什么协议端口是否已经聚合好了这三个问题问完至少能避开80%的bond故障。希望这篇整理对你也有用。