尧图网站建设 
1. 网卡绑定到底解决什么问题1.1 为什么服务器需要多网卡却只能用一个IP先说我自己的经历。早年间维护一台业务服务器上面插了两块千兆网卡一块接内网一块接存储结果业务流量一大内网那块网卡直接跑满CPU中断也跟着飙高业务方大半夜给我打电话。当时第一个想法是能不能把两块网卡合起来用做成一个逻辑口这样带宽翻倍还能防单点故障。后来一查Linux内核早就带了bonding模块这也就是今天要聊的网卡绑定或者说Bond。在做Linux服务器运维或者网络规划的时候很多人都会遇到一个很朴素的场景机器上明明有多个物理网口但业务上只能配置一个IP剩下的口要么闲着要么只能走别的网段。如果想让多个物理网卡干同一件事要么用多IP手动分流要么就得靠链路聚合。Linux bonding就是内核自带的链路聚合方案它能把两个或更多物理网卡绑定成一个虚拟的逻辑网卡对外表现为一个IP、一个MAC地址底层报文却可以按策略走不同的物理链路。这里说的Bond 0-6指的是bonding的7种工作模式编号从mode 0到mode 6。网上很多教程讲bonding上来就贴配置文件但你问他为什么要选mode 4而不是mode 1他答不上来。这篇博文我打算把原理讲透再把从实验环境到生产环境的完整配置流程走一遍最后把踩过的坑列成表格照着排查就行。1.2 三句话总结Bonding的核心收益Bonding能解决的问题归纳起来就三类一是高可用。某一块物理网卡出现故障比如网线被踢掉、交换机端口down掉、网卡模块松动bonding可以把流量自动切换到其他健康的网卡上对上层应用透明。这个过程依赖链路检测机制通常是miimon或者arp_interval几秒钟内完成切换。二是带宽聚合。多块千兆网卡绑在一起理论上可以跑出接近2G、4G的吞吐前提是选对模式。注意我说的是“选对模式”因为有的模式在特定场景下带宽不升反降后面会细说。三是负载均衡。bonding可以把不同类型的流量或不同会话的流量分散到多块物理网卡上降低单网卡的负载压力。这个“不同类型的流量”听上去简单实际在内核里怎么分流就是模式之间的核心差异也是新手最容易迷糊的地方。1.3 Bonding和别的方案比优势在哪儿有人可能会问现在交换机和网卡不是也有LACPLink Aggregation Control Protocol吗和Linux bonding有什么区别这里要分清楚两个概念。LACP是IEEE 802.3ad标准定义的链路聚合控制协议它是跑在交换机和你服务器之间的一种协商协议。Linux bonding的mode 4就是802.3ad它对内依赖bonding驱动对外依赖交换机开启LACP。换句话说bonding是操作系统层面的实现LACP是它和对端交换机打交道的协议。至于网卡厂商自己的NIC Teaming比如Intel的ANS、Broadcom的BACS那是厂商私有方案很多已经不怎么维护了还要装额外驱动远不如内核自带的bonding来得通用。还有一点很关键bonding是内核内置模块CentOS、Ubuntu、Debian全系列都能用虚拟化平台里只要给虚拟机分配了多张虚拟网卡同样可以绑定。你不需要安装额外的用户态软件不需要编译内核配置文件写明白就能用。2. Bond 0-6 模式原理拆解与选型建议2.1 mode 0round-robin轮询模式mode 0的转发逻辑最简单按报文顺序轮流从每块物理网卡发出去。第一个包走eth0第二个包走eth1第三个包又走eth0依次类推在所有slave网卡之间轮转。这种模式的好处是配置简单不依赖交换机任何特殊配置只要交换机端口都在同一个广播域里就行。但它有一个非常坑的问题报文乱序。因为在高速传输时前一个包走eth0、后一个包走eth1两条物理链路的时延如果有细微差别接收端的TCP栈就会收到乱序数据包触发快速重传导致TCP吞吐反而下降。我试过在千兆环境里用iperf压mode 0两条链路聚合起来的吞吐有时候还不如单网卡。所以在生产环境里我基本不建议用mode 0。它只适合某些对顺序不敏感的UDP组播场景或者你知道流量很小、纯粹想利用多网卡做简单冗余但又不关心顺序的场合。如果只是想冗余mode 1更稳。2.2 mode 1active-backup主备模式这一种是最多人用的模式也是我认为新手入门最该先理解透的模式。它只有一个主网卡在工作另一个网卡处于备份状态主网卡链路故障时备份网卡顶上MAC地址会由bond虚拟接口统一接管。切换速度取决于链路检测机制如果miimon100理论上100毫秒就能感知链路down实际切换时间一般在1秒以内。mode 1不需要交换机做任何配置两块网卡接在同一台交换机或者两台交换机上都行只要二层能通。生产环境里我经常用它来做双网卡冗余特别是那种跑数据库、虚拟化的机器带宽不是瓶颈稳定性才是第一诉求。需要注意的是如果你希望指定某块卡作为主卡可以设置primaryeth0参数这样只要eth0链路正常流量始终走eth0eth1永远在待命。2.3 mode 2balance-xor异或模式mode 2的转发规则是用报文的源MAC和目的MAC做一个异或计算再对slave网卡数量取模算出来的结果决定从哪块网卡发出。同一对MAC地址之间的流量始终走同一条链路所以不会像mode 0那样产生报文乱序这是它的最大优势。但这个模式对交换机有要求需要两端配置静态链路聚合也就是说交换机端口要做手工捆绑不跑LACP协商。一般来说如果交换机不支持LACP又想临时做多链路负载分担可以考虑mode 2。不过我有一次在某个老交换机上配了静态聚合服务器这边用mode 2跑了两个月没问题后来交换机升级固件后聚合组配置自动失效了业务瞬间断了排查起来特费劲。这种场景还是优先mode 4更规范。2.4 mode 3broadcast广播模式mode 3的逻辑很直接每一条报文同时从所有slave网卡发出去。它天然具备最高的链路冗灾能力因为同一个包所有口都发了只要还有一块网卡是好的对端就能收到。但我从来没在生产环境见过有人用它因为带宽完全被浪费了发一份数据要占N倍的链路带宽而且大量重复报文会干扰交换机的MAC表学习反而可能造成广播风暴。mode 3唯一的适用场景大概是某些严格要求“所有链路同一时刻必须收到相同数据”的特殊工业控制环境或者做实验验证广播行为。日常服务器场景直接忽略这个模式就行。2.5 mode 4802.3adLACP动态聚合模式这是现代数据中心里最受推荐也最被广泛使用的模式。它在服务器端通过LACP协议里的LACPDU报文和交换机协商动态建立链路聚合组。只要交换机开启了LACP通常是接口模式配置为active或passive两端就能自动协商聚合不需要手工把端口绑到一起。mode 4转发数据的哈希策略和mode 2类似默认用报文的源MAC和目的MAC做异或取模但可以通过xmit_hash_policy参数调整支持layer2、layer23、layer34三种策略。生产环境中如果流量主要是多个客户端访问服务器建议用layer23或layer34这样哈希更均匀能有效避免哈希碰撞导致某条链路打满其他链路空闲。我实测过一个场景一台双千兆绑定的nginx服务器用mode 4 layer34策略用多台压测机并发请求单会话流量能被分散到两条链路上总吞吐约1.8Gbps相较于mode 1的双千兆只走一条链路提升非常明显。但如果你只有单个连接在传输文件那无论什么策略都只能走一条链路这是哈希算法的本质限制。使用mode 4的前提是交换机和网卡驱动都支持LACP。如果是虚拟机网卡VMware的虚拟交换机默认把LACP当作普通帧透传需要提前把分布式交换机或标准交换机的链路聚合策略配好否则LACPDU不通bond0起不来。物理机的话网卡驱动一般都能处理但我在部分老的Broadcom网卡上遇到过lacp协商成功后流量不稳定后来更新了固件才算解决。2.6 mode 5与mode 6balance-tlb / balance-alb自适应负载均衡模式mode 5叫adaptive transmit load balancing中文叫发送端负载均衡它不需要交换机做任何聚合配置就能根据每块slave网卡的实时负载重传次数、队列积压等把发送流量动态分配到最空闲的链路上。但接收流量始终绑定在某一张网卡上所以总带宽上限其实没有翻倍。mode 6叫adaptive load balancing它在mode 5的基础上通过ARP协商对接收方向也做了负载均衡。它会主动修改ARP报文中的源MAC地址让对端设备把不同的ARP请求、不同会话的返回流量分配到不同的物理网卡上。这个模式的好处是零交换机配置开箱即用坏处是它通过ARP欺骗的方式库内协议术语就叫ARP协商来调整接收流量在某些安全设备或者交换机端口安全功能面前会被拦甚至可能导致对端ARP缓存反复刷新网络抖动。我自己的建议如果交换机不支持聚合又要多网卡分担流量mode 6要比mode 0靠谱得多至少它不会产生报文乱序。但如果你是拿它跑正经业务建议还是规划好交换机配置直接用mode 4因为mode 6的ARP处理在某些场景下对CPU的消耗也不低。2.7 模式选型速查表模式名称是否需要交换机支持带宽聚合效果适用场景0round-robin不需要理论上叠加实际可能乱序不推荐用于常规业务1active-backup不需要不叠加双网卡冗余、虚拟化宿主机、数据库2balance-xor需要静态链路聚合可叠加无法启用LACP的旧环境3broadcast不需要不叠加且有冗余特殊广播场景一般不使用4802.3ad需要LACP可叠加且稳定生产环境首选Web/文件服务5balance-tlb不需要仅发送方向叠加无法配置交换机聚合的发送密集型业务6balance-alb不需要双向均可叠加零交换机配置的负载均衡需求3. 实验环境准备与基础配置3.1 环境清单与关键前置条件我自己做实验用的是VMware Workstation里的一台CentOS 7.9虚拟机分配了4块虚拟网卡全部接到同一个VMnet虚拟交换机上。4块卡看着多其实绑定实验至少需要2块卡我准备4块是为了验证多链路故障切换和负载均衡的效果。如果你手头只有2块也够用mode 0、1、4都是2块就能演示的。实验环境清单大致如下操作系统CentOS 7.9 / CentOS 8 / Ubuntu 22.04都可以命令略有差异本文以CentOS为主物理网卡4块网卡无需配置IP仅做bonding的slave交换机实验环境是VMware虚拟交换机直接支持frame透传不需要额外配置物理机环境需要在对端交换机上开启对应模式支持这里后面会专门强调bonding模块内核自带一般无需额外安装可以用modprobe bonding加载这里有一个容易忽略的点就是网卡的设备命名。CentOS 7以后默认使用一致性网络设备命名网卡名可能叫eno1、eno2、ens33、ens34或者vmnet接口下叫ens256之类的不一定是你心里想的eth0。别上手就写eth0的配置先用命令看清楚。3.2 查看网卡信息、驱动与固件状态开实验前先运行下面这几条命令把环境摸清楚。ip link show [rootlocalhost ~]# ip link show 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens33: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:01 brd ff:ff:ff:ff:ff:ff 3: ens34: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:02 brd ff:ff:ff:ff:ff:ff 4: ens35: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:03 brd ff:ff:ff:ff:ff:ff 5: ens36: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:04 brd ff:ff:ff:ff:ff:ff说明一下我这个环境里的网卡名就是ens33、ens34、ens35、ens36后面对应的配置文件也叫ifcfg-ens33、ifcfg-ens34以此类推。不同机器网卡名不一样但你只要按自己的ip link输出对应就好。再看一下网卡驱动的信息ethtool -i ens33 driver: e1000 version: 7.3.21-k8-NAPI firmware-version: bus-info: 0000:02:01.0这个输出告诉我们虚拟机用的网卡驱动是e1000这是Intel的经典虚拟网卡驱动。如果你的是物理机可能看到ixgbe、i40e这些万兆驱动或者是mellanox的mlx5_core。驱动信息有时候能解释为什么某个bond模式在你的机器上表现异常比如老驱动对LACP的支持不好。实验环境不需要深究但生产环境建议先查一下驱动和固件版本能不能匹配你要用的模式。3.3 加载bonding内核模块bonding本身是一个内核模块先试试能不能加载modprobe bonding lsmod | grep bonding bonding 152976 0如果没有任何输出说明模块没有加载成功可能是内核里没编译这个模块可以用modinfo bonding查一下或者换一个带有完整内核模块的操作系统。CentOS默认内核肯定带这个基本不用焦虑。为了确保系统重启后bonding模块自动加载建议在/etc/modprobe.d/bonding.conf里写一行alias bond0 bonding options bonding mode4 miimon100这里有几个细节我多说一句。alias bond0 bonding的意思是当内核创建bond0接口时自动加载bonding模块options bonding mode4 miimon100则给模块设置了默认参数。但注意这个默认参数只是给“没有在ifcfg文件里指定参数”的情况兜底的。实际配置时我更推荐把mode和miimon写在ifcfg-bond0文件里这样每个bond接口可以有不同的mode不至于所有bond0、bond1都被摁在同一个模式上。3.4 用配置文件还是nmcli我给你的建议在CentOS 7/8里配置网络有两种主要方式直接编辑/etc/sysconfig/network-scripts/下的ifcfg文件或者用NetworkManager提供的nmcli命令。如果你是刚接触bonding我强烈建议直接编辑配置文件。原因是网上90%的教程都是基于ifcfg文件的你搜资料最容易对上号而且配置文件理解起来更直观每行参数对应一个属性出错了好排查。nmcli的语法虽然简洁但一行命令要拆成多个子命令和参数出了问题报错信息不够直观对新手不太友好。我自己的服务器一般会直接禁用NetworkManager接管bond接口或者干脆只用nmcli一次配好然后systemctl stop NetworkManager。为什么因为NetworkManager在某些版本里会自动检测网卡状态变化管理不当会把手工配置覆盖掉。生产环境求稳我推荐直接用传统network服务来管理bond接口方法如下systemctl stop NetworkManager systemctl disable NetworkManager systemctl restart network有些新版本系统里network服务默认被NetworkManager取代了如果你执行systemctl restart network提示找不到服务那就别停NetworkManager改用nmcli来管理。这个问题在CentOS 8和大部分Stream版本上尤其常见我后面专门说。4. 实操Bond配置全流程以mode 4为例4.1 创建bond0接口配置文件现在开始正式配置。我以mode 4作为示例因为它是生产环境最常用、验证起来也最能体现bandwidth聚合效果的模式。第一步创建/etc/sysconfig/network-scripts/ifcfg-bond0文件DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes ONBOOTyes BOOTPROTOnone IPADDR192.168.10.10 NETMASK255.255.255.0 GATEWAY192.168.10.1 BONDING_OPTSmode4 miimon100 xmit_hash_policylayer34简单解释一下每个字段的作用。DEVICEbond0是接口名TYPEBond告诉系统这是一个bond接口BONDING_MASTERyes表示这台机器上由bond接口充当master角色它的slave是谁由后面引用的网卡决定。IPADDR这块不用多说就是逻辑接口的IP信息slave网卡上坚决不配IP否则会出现双IP冲突。重点看BONDING_OPTS这一行。mode4对应802.3admiimon100表示每100毫秒检测一次链路状态如果发现链路down就会触发切换。xmit_hash_policylayer34是哈希策略含义是计算源IP、目的IP、源端口、目的端口四元组来做负载均衡。如果你不在乎端口维度只想按IP分摊也可以选layer23但效果略粗糙。4.2 配置slave物理网卡第二步配置两个从接口。以ens33为例编辑/etc/sysconfig/network-scripts/ifcfg-ens33DEVICEens33 NAMEens33 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes同理再编辑ens34内容完全一样就是把DEVICE和NAME改成对应的网卡名。这里有个关键点我在早期踩过坑slave接口里绝对不能有IPADDR、NETMASK、GATEWAY这些字段也不要设置HWADDR除非你真的清楚自己在干什么。HWADDR字段在某些场景下会导致绑定后MAC漂移混乱除非你要固定网卡槽位否则不建议写。如果你手上有4块网卡想全部绑到bond0里就再如法炮制配置ens35和ens36。slave数量理论上没有上限但每加一块卡mode 4的哈希取模分母就变大流量分担更平均。我这次实验用4块卡验证了尾链路故障和整体吞吐效果比2块卡更明显。4.3 交换机侧该做什么实验环境跳过生产必看实验环境如果不涉及物理交换机这一段可以直接跳过。但一旦上了生产这一步没做对bond0的LACP协商会一直失败链路处于down状态业务直接挂掉。如果交换机是Cisco接口配置类似interface GigabitEthernet0/1 channel-group 1 mode active switchport mode access interface GigabitEthernet0/2 channel-group 1 mode active switchport mode access如果交换机是华为配置类似interface Eth-Trunk1 mode lacp-static port link-type trunk interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1注意这里两边模式要匹配服务器mode 4是LACP主动方交换机侧可以配active也可以配passive只要有一端主动发LACPDU就能协商成功。如果交换机侧配置的是静态手工聚合比如Cisco的mode on华为的手工负载分担那就等于服务器这边的mode 4不匹配了这个时候你应该把服务器改成mode 2balance-xor因为静态聚合模式下LACP协商不生效。这个细节是很多故障的根源。我见过不止一个同事在华为交换机上配了手工链路聚合服务器却用的是mode 4结果lacp状态一直显示down查了半天最后才找到原因服务器的LACPDU发出去了交换机手工聚合端口根本不回应。4.4 重启网络并验证bond0是否生效配置完成后重启网络服务使配置生效systemctl restart network重启后先确认接口状态ip link show bond0 10: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:01 brd ff:ff:ff:ff:ff:ff然后看bond0的详细信息cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer34 (1) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Active Aggregator Info: Aggregator ID: 1 Aggregate number of ports: 4 Actor Chosen State: 4 Local Rx Count: 41 Local Tx Count: 60 Slave Interface: ens33 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:0c:29:xx:xx:01 Slave queue ID: 0 Aggregator ID: 1 ...只要看到每个slave接口的MII Status都是upSpeed是1000 MbpsDuplex是fullAggregator ID一致说明绑定成功。如果某一行的Speed显示10 Mbps或者Unknown那基本可以判断这个口物理链路有问题或者对端交换机端口没起来。4.5 实时验证拔网线看切换、压测看吞吐配置完之后先别急着收工我自己习惯做两个验证动作。第一件事测故障切换。在ping业务地址的同时拔掉其中一个slave网卡对应的网线虚拟机里可以执行ip link set ens33 down模拟网线断开观察ping丢包情况ping 192.168.10.10 -i 0.2 64 bytes from 192.168.10.10: icmp_seq1 ttl64 time0.389 ms 64 bytes from 192.168.10.10: icmp_seq2 ttl64 time0.311 ms 64 bytes from 192.168.10.10: icmp_seq3 ttl64 time0.402 ms 64 bytes from 192.168.10.10: icmp_seq4 ttl64 time1.903 ms 64 bytes from 192.168.10.10: icmp_seq5 ttl64 time0.365 ms从seq4的时延突然变高可以看出链路切换发生了但并没有实际丢包。如果你看到连续几个超时后才恢复通常是miimon设置太长或者交换机端口down通知太慢我后面会展开说。第二件事用iperf压测聚合带宽。我在这台服务器的bond0上起了iperf服务端在另一台同网段机器上跑iperf客户端iperf3 -c 192.168.10.10 -P 4 -t 30-P 4表示开4个并发TCP流。如果一切正常总吞吐应该能超过单网卡极限。我在实验环境里4块千兆网卡绑定后跑出了约3.1Gbps的总吞吐虽然达不到严格的4G线速但比单网卡的940Mbps提升非常明显。重点说明如果只用单个TCP流跑iperf3 -c 192.168.10.10 -t 30那吞吐基本还是940Mbps左右因为一条TCP流只会哈希到一条物理链路上这是mode 4的正常表现不是网卡坏了。4.6 如何在bond模式之间切换实验过程中你可能想对比mode 1和mode 4的效果。切换方法很简单修改ifcfg-bond0里的BONDING_OPTS然后重启网络即可BONDING_OPTSmode1 miimon100 primaryens33primaryens33是mode 1特有的参数指定ens33作为主网卡其他网卡做备胎。切换模式后注意观察/proc/net/bonding/bond0里的Bonding Mode字段是否变成了你想要的模式。如果切换后聚合链路状态异常先把两端的LACP配置梳理一下因为mode 1不需要LACPmode 4需要反之亦然。5. 常见问题与排查技巧实录5.1 问题速查表我踩过的坑和树下的经验现象可能原因排查/解决思路bond0启动后一直显示DOWNLACP协商失败交换机侧没配置聚合口检查交换机接口是否有channel-group/eth-trunk配置两端LACP模式是否匹配slave网卡状态显示UP但bond0总吞吐上不去哈希策略粒度太粗多条TCP流哈希到同一物理口换成xmit_hash_policylayer34再压测对比拔掉一根网线后丢包超过2秒miimon设置太长或交换机没有开启链路down快速通知把miimon改到50-100ms交换机开启link fault notificationmode 1配置后地址ping不通primary写错网卡名或备卡和主卡的VLAN/物理隔离不对确认primary对应网卡是否在up状态ip link show确认重启系统后bond0消失没设置ONBOOTyes或NetworkManager接管干扰检查ifcfg-bond0的ONBOOT关停NetworkManagermode 6下对端设备ARP表频繁漂移交换机开启端口安全或DHCP snooping关闭端口安全相关功能或者改用mode 4bond0的MAC地址和某个slave一致导致冲突没有在bond层面固化MAC配置文件中增加MACADDR固定一个虚拟MAC但注意别和物理网卡冲突压测时吞吐忽高忽低物理链路速率或双工模式未协商一致用ethtool ens33确认Speed和Duplex为1000/full这个表格基本覆盖了我这几年接到的大部分bonding咨询。下面挑三个最常见的场景详细展开把排查思路讲透。5.2 为什么slave网卡显示UPbond0却是DOWN这个问题非常经典多半出在mode 4上。你明明在ifcfg里把ens33、ens34都设成了SLAVEyesip link show也显示它们都是UP但bond0就是起不来cat /proc/net/bonding/bond0里显示MII Status: down。我的排查路径是这样的。先确认bond0配置文件里的mode是不是4如果是4去交换机上看聚合口状态如果是手工聚合两端不匹配就会一直down。再看系统日志tail -100 /var/log/messages | grep -i bond如果看到类似bond0: 802.3ad failed to create aggregator的报错那基本就是LACPDU没收到对端回应。这时候用tcpdump抓一下LACPDU报文tcpdump -i ens33 -e -nn ether proto 0x8809LACPDU的ethertype是0x8809只要交换机在发这里就一定能抓到。抓不到就说明交换机侧没启用LACP或者中间有设备把LACPDU当普通帧丢弃了。很多虚拟化环境里的虚拟交换机默认不转发LACPDU这也是虚拟机里mode 4配置完了却没反应的原因。我建议在VMware实验环境里如果发现LACP协商有问题直接换个模式做验证别在虚拟交换机配置上耗太多时间。5.3 miimon和arp_interval到底配哪个这是bonding配置中另一个常见困惑。miimon是基于网卡物理链路状态的检测方式网卡驱动上报link up/down事件bonding感知到这个变化再决定是否切换适合绝大部分场景开销也小。arp_interval则是通过定时发送ARP请求来检测链路连通性不仅检测物理链路还能发现对端设备不可达的情况属于更上层的健康检查。但arp_interval有一个坑它依赖ARP正常收发如果你的网络里有防火墙、ARP过滤等安全策略就会导致误判链路故障。而且arp_interval的配置还需要配合arp_ip_target参数指定用来探测的目标IP。目标IP必须要能响应ARP否则bonding会认为网络不通不停切换链路业务反而受影响。我的经验是默认优先用miimon100。只有在跨设备链路比如网线中间还隔了光电转换器或者需要检测对端三层可达性的场景才考虑配合arp_interval使用。而且设置arp_interval后建议把miimon去掉两个同时开有可能出现检测结果互相矛盾的情况。BONDING_OPTSmode1 miimon0 arp_interval1000 arp_ip_target192.168.10.1这种配置的含义是每1秒发一次ARP探测192.168.10.1如果多次没有回应就认为链路有问题切换到另一块网卡。5.4 重启网络后bond配置丢失多半是NetworkManager背锅这个问题在CentOS 8/RHEL 8以后特别常见。系统默认用NetworkManager管理网络如果你手工编辑了ifcfg文件NetworkManager可能在下一次配置变更时覆盖你写的参数。表现为配置完bond0当时好用一重启或者重启网络服务之后bond0消失了或者变成普通接口了。我的处理办法是要么从一开始就用nmcli配置bonding让NetworkManager自己管理全部网络配置要么就把NetworkManager彻底关掉回归传统的network服务。在CentOS 7里通常没问题因为network服务和NetworkManager可以共存只是你要注意ifcfg文件里不要把NM_CONTROLLED设置成yes在CentOS 8及之后有些版本你就算关掉NetworkManagernetwork服务也不存在了只能靠nmcli的connection配置这部分查一下系统版本就知道该走哪条路。如果用nmclibonding的配置大概是这样的nmcli con add type bond ifname bond0 mode 4 ip4 192.168.10.10/24 nmcli con add type ethernet ifname ens33 master bond0 nmcli con add type ethernet ifname ens34 master bond0 nmcli con up bond0生成之后NetworkManager会把配置写进/etc/sysconfig/network-scripts/对应的keyfile里后续管理用nmcli con mod来改不要再去直接编辑ifcfg文件。6. 一些实验心得和更进一步的玩法最后再写点我在实际使用里的体会。如果你是第一次做bonding实验我建议顺序是这样的先拿两块网卡配mode 1理解active-backup的工作流程看/proc/net/bonding/bond0的输出变化再改成mode 4在允许LACP的交换机或虚拟交换机环境里打通用iperf看聚合带宽。这样一个由简到繁的过程比上来就配mode 6要稳得多。Bonding配置本身不难难点全在于理解每个模式背后的链路行为和交换机配合方式。我在生产环境里见过太多网络疑难杂症最后定位到bond配置上时大多数情况都是模式选型问题和两端配置不匹配问题。建议所有跑bond的生产机器在操作前先备份ifcfg文件操作后记录ethtool输出的速率和双工模式方便出问题时对比。如果你想进一步扩展实验可以试试把bond接口上叠加VLAN也就是常说的VLAN over Bond很多NFV和云平台场景里就是这种用法。具体做法是在bond0之上创建bond0.10这样的VLAN子接口配置方式类似普通VLAN接口但父接口是bond0而不是物理网卡。这样一套下来你对Linux网络协议栈的理解又会深一层。我在实际配置bond时还有一个习惯任何改动后都重启网络并立刻用journalctl -u network查看日志确认没有报错。这个习惯帮我避免了很多“配置看着没问题、一重启才崩溃”的情况。希望对你有用。 Linux网卡绑定Bond 0-6模式详解与配置实践
1. 网卡绑定到底解决什么问题1.1 为什么服务器需要多网卡却只能用一个IP先说我自己的经历。早年间维护一台业务服务器上面插了两块千兆网卡一块接内网一块接存储结果业务流量一大内网那块网卡直接跑满CPU中断也跟着飙高业务方大半夜给我打电话。当时第一个想法是能不能把两块网卡合起来用做成一个逻辑口这样带宽翻倍还能防单点故障。后来一查Linux内核早就带了bonding模块这也就是今天要聊的网卡绑定或者说Bond。在做Linux服务器运维或者网络规划的时候很多人都会遇到一个很朴素的场景机器上明明有多个物理网口但业务上只能配置一个IP剩下的口要么闲着要么只能走别的网段。如果想让多个物理网卡干同一件事要么用多IP手动分流要么就得靠链路聚合。Linux bonding就是内核自带的链路聚合方案它能把两个或更多物理网卡绑定成一个虚拟的逻辑网卡对外表现为一个IP、一个MAC地址底层报文却可以按策略走不同的物理链路。这里说的Bond 0-6指的是bonding的7种工作模式编号从mode 0到mode 6。网上很多教程讲bonding上来就贴配置文件但你问他为什么要选mode 4而不是mode 1他答不上来。这篇博文我打算把原理讲透再把从实验环境到生产环境的完整配置流程走一遍最后把踩过的坑列成表格照着排查就行。1.2 三句话总结Bonding的核心收益Bonding能解决的问题归纳起来就三类一是高可用。某一块物理网卡出现故障比如网线被踢掉、交换机端口down掉、网卡模块松动bonding可以把流量自动切换到其他健康的网卡上对上层应用透明。这个过程依赖链路检测机制通常是miimon或者arp_interval几秒钟内完成切换。二是带宽聚合。多块千兆网卡绑在一起理论上可以跑出接近2G、4G的吞吐前提是选对模式。注意我说的是“选对模式”因为有的模式在特定场景下带宽不升反降后面会细说。三是负载均衡。bonding可以把不同类型的流量或不同会话的流量分散到多块物理网卡上降低单网卡的负载压力。这个“不同类型的流量”听上去简单实际在内核里怎么分流就是模式之间的核心差异也是新手最容易迷糊的地方。1.3 Bonding和别的方案比优势在哪儿有人可能会问现在交换机和网卡不是也有LACPLink Aggregation Control Protocol吗和Linux bonding有什么区别这里要分清楚两个概念。LACP是IEEE 802.3ad标准定义的链路聚合控制协议它是跑在交换机和你服务器之间的一种协商协议。Linux bonding的mode 4就是802.3ad它对内依赖bonding驱动对外依赖交换机开启LACP。换句话说bonding是操作系统层面的实现LACP是它和对端交换机打交道的协议。至于网卡厂商自己的NIC Teaming比如Intel的ANS、Broadcom的BACS那是厂商私有方案很多已经不怎么维护了还要装额外驱动远不如内核自带的bonding来得通用。还有一点很关键bonding是内核内置模块CentOS、Ubuntu、Debian全系列都能用虚拟化平台里只要给虚拟机分配了多张虚拟网卡同样可以绑定。你不需要安装额外的用户态软件不需要编译内核配置文件写明白就能用。2. Bond 0-6 模式原理拆解与选型建议2.1 mode 0round-robin轮询模式mode 0的转发逻辑最简单按报文顺序轮流从每块物理网卡发出去。第一个包走eth0第二个包走eth1第三个包又走eth0依次类推在所有slave网卡之间轮转。这种模式的好处是配置简单不依赖交换机任何特殊配置只要交换机端口都在同一个广播域里就行。但它有一个非常坑的问题报文乱序。因为在高速传输时前一个包走eth0、后一个包走eth1两条物理链路的时延如果有细微差别接收端的TCP栈就会收到乱序数据包触发快速重传导致TCP吞吐反而下降。我试过在千兆环境里用iperf压mode 0两条链路聚合起来的吞吐有时候还不如单网卡。所以在生产环境里我基本不建议用mode 0。它只适合某些对顺序不敏感的UDP组播场景或者你知道流量很小、纯粹想利用多网卡做简单冗余但又不关心顺序的场合。如果只是想冗余mode 1更稳。2.2 mode 1active-backup主备模式这一种是最多人用的模式也是我认为新手入门最该先理解透的模式。它只有一个主网卡在工作另一个网卡处于备份状态主网卡链路故障时备份网卡顶上MAC地址会由bond虚拟接口统一接管。切换速度取决于链路检测机制如果miimon100理论上100毫秒就能感知链路down实际切换时间一般在1秒以内。mode 1不需要交换机做任何配置两块网卡接在同一台交换机或者两台交换机上都行只要二层能通。生产环境里我经常用它来做双网卡冗余特别是那种跑数据库、虚拟化的机器带宽不是瓶颈稳定性才是第一诉求。需要注意的是如果你希望指定某块卡作为主卡可以设置primaryeth0参数这样只要eth0链路正常流量始终走eth0eth1永远在待命。2.3 mode 2balance-xor异或模式mode 2的转发规则是用报文的源MAC和目的MAC做一个异或计算再对slave网卡数量取模算出来的结果决定从哪块网卡发出。同一对MAC地址之间的流量始终走同一条链路所以不会像mode 0那样产生报文乱序这是它的最大优势。但这个模式对交换机有要求需要两端配置静态链路聚合也就是说交换机端口要做手工捆绑不跑LACP协商。一般来说如果交换机不支持LACP又想临时做多链路负载分担可以考虑mode 2。不过我有一次在某个老交换机上配了静态聚合服务器这边用mode 2跑了两个月没问题后来交换机升级固件后聚合组配置自动失效了业务瞬间断了排查起来特费劲。这种场景还是优先mode 4更规范。2.4 mode 3broadcast广播模式mode 3的逻辑很直接每一条报文同时从所有slave网卡发出去。它天然具备最高的链路冗灾能力因为同一个包所有口都发了只要还有一块网卡是好的对端就能收到。但我从来没在生产环境见过有人用它因为带宽完全被浪费了发一份数据要占N倍的链路带宽而且大量重复报文会干扰交换机的MAC表学习反而可能造成广播风暴。mode 3唯一的适用场景大概是某些严格要求“所有链路同一时刻必须收到相同数据”的特殊工业控制环境或者做实验验证广播行为。日常服务器场景直接忽略这个模式就行。2.5 mode 4802.3adLACP动态聚合模式这是现代数据中心里最受推荐也最被广泛使用的模式。它在服务器端通过LACP协议里的LACPDU报文和交换机协商动态建立链路聚合组。只要交换机开启了LACP通常是接口模式配置为active或passive两端就能自动协商聚合不需要手工把端口绑到一起。mode 4转发数据的哈希策略和mode 2类似默认用报文的源MAC和目的MAC做异或取模但可以通过xmit_hash_policy参数调整支持layer2、layer23、layer34三种策略。生产环境中如果流量主要是多个客户端访问服务器建议用layer23或layer34这样哈希更均匀能有效避免哈希碰撞导致某条链路打满其他链路空闲。我实测过一个场景一台双千兆绑定的nginx服务器用mode 4 layer34策略用多台压测机并发请求单会话流量能被分散到两条链路上总吞吐约1.8Gbps相较于mode 1的双千兆只走一条链路提升非常明显。但如果你只有单个连接在传输文件那无论什么策略都只能走一条链路这是哈希算法的本质限制。使用mode 4的前提是交换机和网卡驱动都支持LACP。如果是虚拟机网卡VMware的虚拟交换机默认把LACP当作普通帧透传需要提前把分布式交换机或标准交换机的链路聚合策略配好否则LACPDU不通bond0起不来。物理机的话网卡驱动一般都能处理但我在部分老的Broadcom网卡上遇到过lacp协商成功后流量不稳定后来更新了固件才算解决。2.6 mode 5与mode 6balance-tlb / balance-alb自适应负载均衡模式mode 5叫adaptive transmit load balancing中文叫发送端负载均衡它不需要交换机做任何聚合配置就能根据每块slave网卡的实时负载重传次数、队列积压等把发送流量动态分配到最空闲的链路上。但接收流量始终绑定在某一张网卡上所以总带宽上限其实没有翻倍。mode 6叫adaptive load balancing它在mode 5的基础上通过ARP协商对接收方向也做了负载均衡。它会主动修改ARP报文中的源MAC地址让对端设备把不同的ARP请求、不同会话的返回流量分配到不同的物理网卡上。这个模式的好处是零交换机配置开箱即用坏处是它通过ARP欺骗的方式库内协议术语就叫ARP协商来调整接收流量在某些安全设备或者交换机端口安全功能面前会被拦甚至可能导致对端ARP缓存反复刷新网络抖动。我自己的建议如果交换机不支持聚合又要多网卡分担流量mode 6要比mode 0靠谱得多至少它不会产生报文乱序。但如果你是拿它跑正经业务建议还是规划好交换机配置直接用mode 4因为mode 6的ARP处理在某些场景下对CPU的消耗也不低。2.7 模式选型速查表模式名称是否需要交换机支持带宽聚合效果适用场景0round-robin不需要理论上叠加实际可能乱序不推荐用于常规业务1active-backup不需要不叠加双网卡冗余、虚拟化宿主机、数据库2balance-xor需要静态链路聚合可叠加无法启用LACP的旧环境3broadcast不需要不叠加且有冗余特殊广播场景一般不使用4802.3ad需要LACP可叠加且稳定生产环境首选Web/文件服务5balance-tlb不需要仅发送方向叠加无法配置交换机聚合的发送密集型业务6balance-alb不需要双向均可叠加零交换机配置的负载均衡需求3. 实验环境准备与基础配置3.1 环境清单与关键前置条件我自己做实验用的是VMware Workstation里的一台CentOS 7.9虚拟机分配了4块虚拟网卡全部接到同一个VMnet虚拟交换机上。4块卡看着多其实绑定实验至少需要2块卡我准备4块是为了验证多链路故障切换和负载均衡的效果。如果你手头只有2块也够用mode 0、1、4都是2块就能演示的。实验环境清单大致如下操作系统CentOS 7.9 / CentOS 8 / Ubuntu 22.04都可以命令略有差异本文以CentOS为主物理网卡4块网卡无需配置IP仅做bonding的slave交换机实验环境是VMware虚拟交换机直接支持frame透传不需要额外配置物理机环境需要在对端交换机上开启对应模式支持这里后面会专门强调bonding模块内核自带一般无需额外安装可以用modprobe bonding加载这里有一个容易忽略的点就是网卡的设备命名。CentOS 7以后默认使用一致性网络设备命名网卡名可能叫eno1、eno2、ens33、ens34或者vmnet接口下叫ens256之类的不一定是你心里想的eth0。别上手就写eth0的配置先用命令看清楚。3.2 查看网卡信息、驱动与固件状态开实验前先运行下面这几条命令把环境摸清楚。ip link show [rootlocalhost ~]# ip link show 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens33: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:01 brd ff:ff:ff:ff:ff:ff 3: ens34: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:02 brd ff:ff:ff:ff:ff:ff 4: ens35: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:03 brd ff:ff:ff:ff:ff:ff 5: ens36: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:04 brd ff:ff:ff:ff:ff:ff说明一下我这个环境里的网卡名就是ens33、ens34、ens35、ens36后面对应的配置文件也叫ifcfg-ens33、ifcfg-ens34以此类推。不同机器网卡名不一样但你只要按自己的ip link输出对应就好。再看一下网卡驱动的信息ethtool -i ens33 driver: e1000 version: 7.3.21-k8-NAPI firmware-version: bus-info: 0000:02:01.0这个输出告诉我们虚拟机用的网卡驱动是e1000这是Intel的经典虚拟网卡驱动。如果你的是物理机可能看到ixgbe、i40e这些万兆驱动或者是mellanox的mlx5_core。驱动信息有时候能解释为什么某个bond模式在你的机器上表现异常比如老驱动对LACP的支持不好。实验环境不需要深究但生产环境建议先查一下驱动和固件版本能不能匹配你要用的模式。3.3 加载bonding内核模块bonding本身是一个内核模块先试试能不能加载modprobe bonding lsmod | grep bonding bonding 152976 0如果没有任何输出说明模块没有加载成功可能是内核里没编译这个模块可以用modinfo bonding查一下或者换一个带有完整内核模块的操作系统。CentOS默认内核肯定带这个基本不用焦虑。为了确保系统重启后bonding模块自动加载建议在/etc/modprobe.d/bonding.conf里写一行alias bond0 bonding options bonding mode4 miimon100这里有几个细节我多说一句。alias bond0 bonding的意思是当内核创建bond0接口时自动加载bonding模块options bonding mode4 miimon100则给模块设置了默认参数。但注意这个默认参数只是给“没有在ifcfg文件里指定参数”的情况兜底的。实际配置时我更推荐把mode和miimon写在ifcfg-bond0文件里这样每个bond接口可以有不同的mode不至于所有bond0、bond1都被摁在同一个模式上。3.4 用配置文件还是nmcli我给你的建议在CentOS 7/8里配置网络有两种主要方式直接编辑/etc/sysconfig/network-scripts/下的ifcfg文件或者用NetworkManager提供的nmcli命令。如果你是刚接触bonding我强烈建议直接编辑配置文件。原因是网上90%的教程都是基于ifcfg文件的你搜资料最容易对上号而且配置文件理解起来更直观每行参数对应一个属性出错了好排查。nmcli的语法虽然简洁但一行命令要拆成多个子命令和参数出了问题报错信息不够直观对新手不太友好。我自己的服务器一般会直接禁用NetworkManager接管bond接口或者干脆只用nmcli一次配好然后systemctl stop NetworkManager。为什么因为NetworkManager在某些版本里会自动检测网卡状态变化管理不当会把手工配置覆盖掉。生产环境求稳我推荐直接用传统network服务来管理bond接口方法如下systemctl stop NetworkManager systemctl disable NetworkManager systemctl restart network有些新版本系统里network服务默认被NetworkManager取代了如果你执行systemctl restart network提示找不到服务那就别停NetworkManager改用nmcli来管理。这个问题在CentOS 8和大部分Stream版本上尤其常见我后面专门说。4. 实操Bond配置全流程以mode 4为例4.1 创建bond0接口配置文件现在开始正式配置。我以mode 4作为示例因为它是生产环境最常用、验证起来也最能体现bandwidth聚合效果的模式。第一步创建/etc/sysconfig/network-scripts/ifcfg-bond0文件DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes ONBOOTyes BOOTPROTOnone IPADDR192.168.10.10 NETMASK255.255.255.0 GATEWAY192.168.10.1 BONDING_OPTSmode4 miimon100 xmit_hash_policylayer34简单解释一下每个字段的作用。DEVICEbond0是接口名TYPEBond告诉系统这是一个bond接口BONDING_MASTERyes表示这台机器上由bond接口充当master角色它的slave是谁由后面引用的网卡决定。IPADDR这块不用多说就是逻辑接口的IP信息slave网卡上坚决不配IP否则会出现双IP冲突。重点看BONDING_OPTS这一行。mode4对应802.3admiimon100表示每100毫秒检测一次链路状态如果发现链路down就会触发切换。xmit_hash_policylayer34是哈希策略含义是计算源IP、目的IP、源端口、目的端口四元组来做负载均衡。如果你不在乎端口维度只想按IP分摊也可以选layer23但效果略粗糙。4.2 配置slave物理网卡第二步配置两个从接口。以ens33为例编辑/etc/sysconfig/network-scripts/ifcfg-ens33DEVICEens33 NAMEens33 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes同理再编辑ens34内容完全一样就是把DEVICE和NAME改成对应的网卡名。这里有个关键点我在早期踩过坑slave接口里绝对不能有IPADDR、NETMASK、GATEWAY这些字段也不要设置HWADDR除非你真的清楚自己在干什么。HWADDR字段在某些场景下会导致绑定后MAC漂移混乱除非你要固定网卡槽位否则不建议写。如果你手上有4块网卡想全部绑到bond0里就再如法炮制配置ens35和ens36。slave数量理论上没有上限但每加一块卡mode 4的哈希取模分母就变大流量分担更平均。我这次实验用4块卡验证了尾链路故障和整体吞吐效果比2块卡更明显。4.3 交换机侧该做什么实验环境跳过生产必看实验环境如果不涉及物理交换机这一段可以直接跳过。但一旦上了生产这一步没做对bond0的LACP协商会一直失败链路处于down状态业务直接挂掉。如果交换机是Cisco接口配置类似interface GigabitEthernet0/1 channel-group 1 mode active switchport mode access interface GigabitEthernet0/2 channel-group 1 mode active switchport mode access如果交换机是华为配置类似interface Eth-Trunk1 mode lacp-static port link-type trunk interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1注意这里两边模式要匹配服务器mode 4是LACP主动方交换机侧可以配active也可以配passive只要有一端主动发LACPDU就能协商成功。如果交换机侧配置的是静态手工聚合比如Cisco的mode on华为的手工负载分担那就等于服务器这边的mode 4不匹配了这个时候你应该把服务器改成mode 2balance-xor因为静态聚合模式下LACP协商不生效。这个细节是很多故障的根源。我见过不止一个同事在华为交换机上配了手工链路聚合服务器却用的是mode 4结果lacp状态一直显示down查了半天最后才找到原因服务器的LACPDU发出去了交换机手工聚合端口根本不回应。4.4 重启网络并验证bond0是否生效配置完成后重启网络服务使配置生效systemctl restart network重启后先确认接口状态ip link show bond0 10: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:xx:xx:01 brd ff:ff:ff:ff:ff:ff然后看bond0的详细信息cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer34 (1) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Active Aggregator Info: Aggregator ID: 1 Aggregate number of ports: 4 Actor Chosen State: 4 Local Rx Count: 41 Local Tx Count: 60 Slave Interface: ens33 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:0c:29:xx:xx:01 Slave queue ID: 0 Aggregator ID: 1 ...只要看到每个slave接口的MII Status都是upSpeed是1000 MbpsDuplex是fullAggregator ID一致说明绑定成功。如果某一行的Speed显示10 Mbps或者Unknown那基本可以判断这个口物理链路有问题或者对端交换机端口没起来。4.5 实时验证拔网线看切换、压测看吞吐配置完之后先别急着收工我自己习惯做两个验证动作。第一件事测故障切换。在ping业务地址的同时拔掉其中一个slave网卡对应的网线虚拟机里可以执行ip link set ens33 down模拟网线断开观察ping丢包情况ping 192.168.10.10 -i 0.2 64 bytes from 192.168.10.10: icmp_seq1 ttl64 time0.389 ms 64 bytes from 192.168.10.10: icmp_seq2 ttl64 time0.311 ms 64 bytes from 192.168.10.10: icmp_seq3 ttl64 time0.402 ms 64 bytes from 192.168.10.10: icmp_seq4 ttl64 time1.903 ms 64 bytes from 192.168.10.10: icmp_seq5 ttl64 time0.365 ms从seq4的时延突然变高可以看出链路切换发生了但并没有实际丢包。如果你看到连续几个超时后才恢复通常是miimon设置太长或者交换机端口down通知太慢我后面会展开说。第二件事用iperf压测聚合带宽。我在这台服务器的bond0上起了iperf服务端在另一台同网段机器上跑iperf客户端iperf3 -c 192.168.10.10 -P 4 -t 30-P 4表示开4个并发TCP流。如果一切正常总吞吐应该能超过单网卡极限。我在实验环境里4块千兆网卡绑定后跑出了约3.1Gbps的总吞吐虽然达不到严格的4G线速但比单网卡的940Mbps提升非常明显。重点说明如果只用单个TCP流跑iperf3 -c 192.168.10.10 -t 30那吞吐基本还是940Mbps左右因为一条TCP流只会哈希到一条物理链路上这是mode 4的正常表现不是网卡坏了。4.6 如何在bond模式之间切换实验过程中你可能想对比mode 1和mode 4的效果。切换方法很简单修改ifcfg-bond0里的BONDING_OPTS然后重启网络即可BONDING_OPTSmode1 miimon100 primaryens33primaryens33是mode 1特有的参数指定ens33作为主网卡其他网卡做备胎。切换模式后注意观察/proc/net/bonding/bond0里的Bonding Mode字段是否变成了你想要的模式。如果切换后聚合链路状态异常先把两端的LACP配置梳理一下因为mode 1不需要LACPmode 4需要反之亦然。5. 常见问题与排查技巧实录5.1 问题速查表我踩过的坑和树下的经验现象可能原因排查/解决思路bond0启动后一直显示DOWNLACP协商失败交换机侧没配置聚合口检查交换机接口是否有channel-group/eth-trunk配置两端LACP模式是否匹配slave网卡状态显示UP但bond0总吞吐上不去哈希策略粒度太粗多条TCP流哈希到同一物理口换成xmit_hash_policylayer34再压测对比拔掉一根网线后丢包超过2秒miimon设置太长或交换机没有开启链路down快速通知把miimon改到50-100ms交换机开启link fault notificationmode 1配置后地址ping不通primary写错网卡名或备卡和主卡的VLAN/物理隔离不对确认primary对应网卡是否在up状态ip link show确认重启系统后bond0消失没设置ONBOOTyes或NetworkManager接管干扰检查ifcfg-bond0的ONBOOT关停NetworkManagermode 6下对端设备ARP表频繁漂移交换机开启端口安全或DHCP snooping关闭端口安全相关功能或者改用mode 4bond0的MAC地址和某个slave一致导致冲突没有在bond层面固化MAC配置文件中增加MACADDR固定一个虚拟MAC但注意别和物理网卡冲突压测时吞吐忽高忽低物理链路速率或双工模式未协商一致用ethtool ens33确认Speed和Duplex为1000/full这个表格基本覆盖了我这几年接到的大部分bonding咨询。下面挑三个最常见的场景详细展开把排查思路讲透。5.2 为什么slave网卡显示UPbond0却是DOWN这个问题非常经典多半出在mode 4上。你明明在ifcfg里把ens33、ens34都设成了SLAVEyesip link show也显示它们都是UP但bond0就是起不来cat /proc/net/bonding/bond0里显示MII Status: down。我的排查路径是这样的。先确认bond0配置文件里的mode是不是4如果是4去交换机上看聚合口状态如果是手工聚合两端不匹配就会一直down。再看系统日志tail -100 /var/log/messages | grep -i bond如果看到类似bond0: 802.3ad failed to create aggregator的报错那基本就是LACPDU没收到对端回应。这时候用tcpdump抓一下LACPDU报文tcpdump -i ens33 -e -nn ether proto 0x8809LACPDU的ethertype是0x8809只要交换机在发这里就一定能抓到。抓不到就说明交换机侧没启用LACP或者中间有设备把LACPDU当普通帧丢弃了。很多虚拟化环境里的虚拟交换机默认不转发LACPDU这也是虚拟机里mode 4配置完了却没反应的原因。我建议在VMware实验环境里如果发现LACP协商有问题直接换个模式做验证别在虚拟交换机配置上耗太多时间。5.3 miimon和arp_interval到底配哪个这是bonding配置中另一个常见困惑。miimon是基于网卡物理链路状态的检测方式网卡驱动上报link up/down事件bonding感知到这个变化再决定是否切换适合绝大部分场景开销也小。arp_interval则是通过定时发送ARP请求来检测链路连通性不仅检测物理链路还能发现对端设备不可达的情况属于更上层的健康检查。但arp_interval有一个坑它依赖ARP正常收发如果你的网络里有防火墙、ARP过滤等安全策略就会导致误判链路故障。而且arp_interval的配置还需要配合arp_ip_target参数指定用来探测的目标IP。目标IP必须要能响应ARP否则bonding会认为网络不通不停切换链路业务反而受影响。我的经验是默认优先用miimon100。只有在跨设备链路比如网线中间还隔了光电转换器或者需要检测对端三层可达性的场景才考虑配合arp_interval使用。而且设置arp_interval后建议把miimon去掉两个同时开有可能出现检测结果互相矛盾的情况。BONDING_OPTSmode1 miimon0 arp_interval1000 arp_ip_target192.168.10.1这种配置的含义是每1秒发一次ARP探测192.168.10.1如果多次没有回应就认为链路有问题切换到另一块网卡。5.4 重启网络后bond配置丢失多半是NetworkManager背锅这个问题在CentOS 8/RHEL 8以后特别常见。系统默认用NetworkManager管理网络如果你手工编辑了ifcfg文件NetworkManager可能在下一次配置变更时覆盖你写的参数。表现为配置完bond0当时好用一重启或者重启网络服务之后bond0消失了或者变成普通接口了。我的处理办法是要么从一开始就用nmcli配置bonding让NetworkManager自己管理全部网络配置要么就把NetworkManager彻底关掉回归传统的network服务。在CentOS 7里通常没问题因为network服务和NetworkManager可以共存只是你要注意ifcfg文件里不要把NM_CONTROLLED设置成yes在CentOS 8及之后有些版本你就算关掉NetworkManagernetwork服务也不存在了只能靠nmcli的connection配置这部分查一下系统版本就知道该走哪条路。如果用nmclibonding的配置大概是这样的nmcli con add type bond ifname bond0 mode 4 ip4 192.168.10.10/24 nmcli con add type ethernet ifname ens33 master bond0 nmcli con add type ethernet ifname ens34 master bond0 nmcli con up bond0生成之后NetworkManager会把配置写进/etc/sysconfig/network-scripts/对应的keyfile里后续管理用nmcli con mod来改不要再去直接编辑ifcfg文件。6. 一些实验心得和更进一步的玩法最后再写点我在实际使用里的体会。如果你是第一次做bonding实验我建议顺序是这样的先拿两块网卡配mode 1理解active-backup的工作流程看/proc/net/bonding/bond0的输出变化再改成mode 4在允许LACP的交换机或虚拟交换机环境里打通用iperf看聚合带宽。这样一个由简到繁的过程比上来就配mode 6要稳得多。Bonding配置本身不难难点全在于理解每个模式背后的链路行为和交换机配合方式。我在生产环境里见过太多网络疑难杂症最后定位到bond配置上时大多数情况都是模式选型问题和两端配置不匹配问题。建议所有跑bond的生产机器在操作前先备份ifcfg文件操作后记录ethtool输出的速率和双工模式方便出问题时对比。如果你想进一步扩展实验可以试试把bond接口上叠加VLAN也就是常说的VLAN over Bond很多NFV和云平台场景里就是这种用法。具体做法是在bond0之上创建bond0.10这样的VLAN子接口配置方式类似普通VLAN接口但父接口是bond0而不是物理网卡。这样一套下来你对Linux网络协议栈的理解又会深一层。我在实际配置bond时还有一个习惯任何改动后都重启网络并立刻用journalctl -u network查看日志确认没有报错。这个习惯帮我避免了很多“配置看着没问题、一重启才崩溃”的情况。希望对你有用。