CentOS8网卡Bond配置实战：nmcli命令详解与排错指南

CentOS8上做网卡Bond，这活儿看着简单，但坑是真不少。很多人还在翻CentOS7时代的老教程，用ifcfg脚本手搓bond配置文件，结果在CentOS8上一跑就发现NetworkManager总是抢权限，或者网卡死活起不来。我在实际维护服务器时用nmcli在CentOS8上做过多次bond配置，包括mode1主备、mode4聚合，以及mode6负载均衡，今天就系统地总结一下这套完整的命令操作流程和踩坑经验。

这个内容适合所有需要给服务器做网卡高可用或带宽扩容的运维同学。不管你是刚接触bond概念的新手，还是已经遇到过bond起不来的老手，这篇文章直接给命令、给参数、给排查思路，按步骤操作就能复现。

1. 设计思路：CentOS8做Bond到底选哪个模式、为什么用nmcli

1.1 先搞清Bond的常见模式与应用场景

网卡bond本质是把多块物理网卡虚拟成一块逻辑网卡，对外呈现一个统一的管理IP。做这件事不外乎两个诉求：要么提高链路可靠性（一块网卡down了另一块自动顶上），要么提高吞吐带宽（多块网卡同时分担流量）。

常见的bond模式有七种，但我们运维实际用到的就三个：

• mode1（active-backup，主备模式）：同一时间只有一块网卡在干活，另一块纯待命。这是使用最广的模式，交换机和服务器之间不需要任何特殊配合，只要交换机支持普通trunk或者access口就行。实际业务中，如果服务器只是需要保证管理口不断线，或者数据库这类对网络稳定性要求极高的场景，选它就够了。

• mode4（802.3ad，动态链路聚合）：多块网卡同时工作，前提是交换机接口必须开启LACP协议。这个模式既能冗余又能提高带宽，但两边配置必须一致，否则链路起不来。适合数据库集群心跳、存储网络这类需要大吞吐又要求高可用的场景。

• mode6（balance-alb，自适应负载均衡）：多块网卡同时收发流量，但不需要交换机做任何配置，靠服务器侧修改ARP报文实现负载分担。它的好处是兼容性好，坏处是CPU开销会高一点，而且某些交换机对它不太友好。测试环境、对交换机没有管控权限的场景可以选择它。

我在生产环境里遇到最多的是mode1和mode4，mode6偶尔用在没法动交换机配置的机房。

1.2 为什么CentOS8上必须用nmcli而不是手工改ifcfg

CentOS8默认使用NetworkManager接管网络配置。这意味着系统里哪怕你手动改了/etc/sysconfig/network-scripts/ifcfg-*文件，NetworkManager也不一定会立刻生效，甚至可能在reload时把配置覆盖掉。很多从CentOS7迁移上来的人在这里就栽了跟头。

nmcli是NetworkManager的命令行管理工具，用它配置bond，本质上是让NetworkManager正确认知并管理整个bond链路，包括物理网卡、bond虚拟接口和IP地址三层关系。它在生成底层ifcfg文件的同时，会把bond相关的参数完整写入配置数据库，重启后不会丢配置，不会被诡异覆盖。

还有一个实际好处：用nmcli配置bond时，改IP、增删从属网卡、切换bond模式，全程不用手写一堆KEY=VALUE段落，命令清晰好排查，出了问题也容易回滚。这在生产服务器上非常重要。

1.3 从整体拓扑理解bond的配置层级

做bond之前，脑子里必须先有一张清晰的三层拓扑图：

底层是物理网卡（ens1f0、ens1f1这类名称），中间是bond虚拟网卡（我们创建bond0），顶层是IP地址所在的连接（名字随便起，比如bond0-ip）。

nmcli配置bond的过程，本质就是把物理网卡“塞”进bond0这个虚拟设备，然后给bond0配上IP并设置管理连接。理解这个层级之后，哪怕命令记不全，你也能从报错信息里判断到底哪一层出了问题。

我见过很多新手直接在物理网卡配置文件里写BONDING_MASTER=yes，然后折腾半天起不来。实际上从CentOS8开始，NetworkManager接管之后，物理网卡只需要作为一个slave，把MASTER指向bond0就够了，IP地址不要写在物理网卡上。这个思路如果不理清楚，后面配置步骤越多越乱。

2. 核心实操：从零配置Bond的完整命令流程

2.1 配置前必须做的网卡环境检查

拿到一台CentOS8服务器，先别急着敲命令，花两分钟看网卡现状，能避免后面大量返工。

查看当前系统里有哪些物理网卡以及它们的连接状态：

nmcli device status

输出会列出设备的类型和连接情况。正常情况下你应该看到多块物理网卡都处于“已断开”或者“已连接”状态，但注意，如果某块网卡已经被NetworkManager接管并且配了IP，那这块网卡在bond配置时必须先处理干净。

再看看当前的network-scripts目录下面有什么残留配置：

ls -l /etc/sysconfig/network-scripts/

CentOS8虽然默认用NetworkManager，但这个目录下的ifcfg文件仍然会存在。如果在CentOS7时代机器上已经手工写过bond配置，建议先把这些残留文件处理干净，否则新旧配置冲突，重启必出幺蛾子。

还有一件非常重要的事：物理网卡的MAC地址会直接影响网络管理。如果服务器之前配过固定IP绑定，记录一下原有管理IP的配置位置，避免做完bond连不上服务器。

2.2 第一步：先给物理网卡“卸妆”

把将要做从属网卡的物理接口原有连接删掉，这一步非常关键。如果物理网卡上还挂着老连接，后续添加bond-slave时会出现“设备已被占用”的错误。

假设我们要用ens1f0和ens1f1这两块物理网卡：

nmcli connection delete "有线连接 1" 2>/dev/null nmcli connection delete "有线连接 2" 2>/dev/null

如果不确定连接的准确名字，执行nmcli connection show查看当前连接列表，再根据网卡名找到对应的连接名称，逐一删除。

删完之后再次执行nmcli device status，确认这两块网卡的状态变成“已断开”，不带任何连接，这就相当于把网卡擦干净了，可以开始做bond。

注意：如果服务器上已经没有其他网卡可以连外网了，这一步操作会让现有SSH连接暂时中断。所以在生产机上做配置时，建议带外管理端口或者本地控制台准备好，或者确认当前SSH连接不依赖这两块网卡。

2.3 创建Bond主连接并配置模式

接下来用nmcli创建bond主连接，命令格式如下：

nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup

这一条命令做了三件事：创建了一个类型为bond的连接配置（con-name为bond0）、对应的内核虚拟接口名（ifname为bond0），同时把模式设置成了active-backup，也就是mode1。

如果你要做mode4，把mode参数改成mode 802.3ad：

nmcli connection add type bond con-name bond0 ifname bond0 mode 802.3ad

做mode6则写成mode balance-alb。

对于mode1，如果需要指定主备顺序，让某一块高优先级的网卡作为主接口，可以在创建时加上primary参数：

nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup primary ens1f0

这样系统启动后会优先使用ens1f0作为主链路，一旦它挂了才切换到ens1f1。这个场景很实用，比如双网卡接不同交换机，你希望流量默认走专线、备用走办公网，只要把主网卡指定清楚并配好对应网段的IP即可。

2.4 把物理网卡作为从属接口加入Bond

bond主连接创建好了，接下来把两块物理网卡添加进去。

关键命令如下：

nmcli connection add type bond-slave con-name bond0-slave1 ifname ens1f0 master bond0 nmcli connection add type bond-slave con-name bond0-slave2 ifname ens1f1 master bond0

注意看，从属连接的con-name一定要和主连接的con-name区分开，这里我用了bond0-slave1、bond0-slave2。ifname填的是真实物理网卡名。master指向bond0。

创建完之后，用下面的命令确认从属连接是否创建成功：

nmcli connection show

这时候你应该能看到三个连接：bond0（主连接）、bond0-slave1、bond0-slave2（从属连接）。

这里有个容易踩的坑：如果你在创建slave时，系统提示设备已经被其他连接占用，说明物理网卡上有Old连接残留，回到第2.2步把残留连接删掉，然后用nmcli device reapply或者nmcli connection up重新拉起来。

2.5 给Bond接口配置IP地址

bond链路建起来了，最后一步是给bond0配IP。

有两种情况。第一种是刚创建的bond0连接还没有IP，直接给主连接设置IPv4地址：

nmcli connection modify bond0 ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.dns "114.114.114.114 8.8.8.8" ipv4.method manual

第二种情况是你希望用DHCP自动获取地址，那就设置成ipv4.method auto：

nmcli connection modify bond0 ipv4.method auto

我个人在生产环境一直推荐手工指定IP，因为服务器就是要稳定，万一DHCP租约出问题，整台服务器的业务就断了。手工从配置复杂性上也就多敲几行命令的成本，但换来的是长期确定性。

IP配完之后，注意启动顺序：一定要先启动bond主连接，再把从属接口连接顶上。直接用以下命令一次性把所有连接拉起来：

nmcli connection up bond0 nmcli connection up bond0-slave1 nmcli connection up bond0-slave2

顺序有讲究。先up bond0，bond0才能作为master接收slave注册。如果你把顺序搞反了，从属网卡会报“找不到master”的错误。

2.6 使用传统方式配置Bond的替代方案与对比

我知道一定有人问：我就想用传统ifcfg文件方式配置行不行？

可以，但CentOS8上建议至少把NetworkManager对那块网卡的接管权限关掉，或者直接用nmcli导入配置。具体方式是在ifcfg文件中写NM_CONTROLLED=no，让NetworkManager完全不碰这块设备。但这样做的代价是你失去nmcli对bond的监控能力，一旦网卡掉线，排查链路状态只能用/proc文件系统。

我自己实测下来：传统方式配置mode1在主备切换速度、稳定性上，和nmcli配出来的没有本质区别，但在配置可读性、可维护性上差多了。特别是你要在CentOS8里同时管多台服务器，nmcli生成的配置统一规范，后来的人接手也容易看懂。

如果你确实要手工写传统配置，给出参考模板（但不推荐在生产使用）：

# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 NM_CONTROLLED=no BOOTPROTO=none ONBOOT=yes IPADDR=192.168.10.10 PREFIX=24 GATEWAY=192.168.10.1 BONDING_MASTER=yes BONDING_OPTS="mode=active-backup miimon=100 primary=ens1f0" # /etc/sysconfig/network-scripts/ifcfg-ens1f0 DEVICE=ens1f0 NM_CONTROLLED=no ONBOOT=yes MASTER=bond0 SLAVE=yes # /etc/sysconfig/network-scripts/ifcfg-ens1f1 DEVICE=ens1f1 NM_CONTROLLED=no ONBOOT=yes MASTER=bond0 SLAVE=yes

写完这些文件后执行systemctl restart network或者重启服务器才能生效。注意CentOS8里network服务默认可能是disabled的，需要先systemctl enable network。但这套方式在RHEL9/CentOS9上已经基本废弃了，学它没有长期价值。

3. 验证与常见故障：Bond到底做成什么样才算成

3.1 确认Bond链路状态和主备角色

配置完成后，不能只看活没起来，要确认bond逻辑链路建立得健康。

最直接的方式是查看内核bond信息：

cat /proc/net/bonding/bond0

这个文件会展示bond的当前模式、从属网卡数量、每块从属网卡的MII状态、链路失败次数、以及当前活跃的从属网卡是谁。

我实际执行后看到的关键段落是：

Bonding Mode: fault-tolerance (active-backup) Primary Slave: ens1f0 (primary_reselect: always) Currently Active Slave: ens1f0 MII Status: up MII Poll Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: ens1f0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Slave Interface: ens1f1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0

看到“Currently Active Slave: ens1f0”就说明现在主链路是ens1f0。如果两块从属网卡的MII Status都是up，而且Speed和Duplex都正常，说明物理层和链路层都通了。

如果哪块网卡显示MII Status: down，通常意味着物理链路没通、网线问题、交换机端口没启用，或者对端交换机的接口被配置成了关闭状态。这个文件是排查bond问题的第一个入口，比看什么管理工具都可靠。

3.2 用ss和ping验证业务层连通性

内核bond状态没问题之后，再验证网络层连通性。从服务器本机ping网关：

ping -I bond0 -c 3 192.168.10.1

通过-I bond0指定走bond接口出去，确认这个虚拟接口能正常通信。

然后确认IP地址已经正确落在bond0上：

ip addr show bond0

输出的inet字段应该是你配的IP地址，并且scope global，表示这个IP已经绑定到bond0，并且路由可达。

另外用ss -tunlp检查业务监听端口是否都正常监听。很多时候做bond的主机同时跑着数据库或者Nginx，端口本来通着，做完bond如果忘了重新加载服务配置，业务端口可能会掉。

3.3 模拟链路故障并测试主备切换

配置mode1的核心价值就是主备切换。配置完之后必须实测一次切换能力，不能在真正故障时才发现切不过去。

使用下面这个命令直接把主网卡的连接断开：

nmcli connection down bond0-slave1

执行之后要立即查看bond状态：

cat /proc/net/bonding/bond0

正常情况下几毫秒内“Currently Active Slave”就会自动切换到ens1f1，MII Status保持up，业务断开时间在网络层几乎感知不到。

验证完成后把从属网卡拉回来：

nmcli connection up bond0-slave1

回来后执行ip addr show和业务访问测试，确认流量自动切回主网卡。

我之前遇到过一种情况：主备切换成功了，但是业务端口在切换瞬间出现大量TCP连接重置。原因其实不是bond的问题，而是应用程序的TCP连接超时重传机制。这一点在切换测试时要跟业务人员提前沟通，并不是所有服务都能做到连接无损切换。

3.4 查看Bond详细信息：ethtool与nmcli的命令组合

除了/proc文件，ethtool可以查看物理网卡的真实链路状态。

ethtool ens1f0

输出里重点看：

Speed: 1000Mb/s Duplex: Full Link detected: yes

“Link detected: no”说明网线没插好或者对端端口down，这种情况bond再配置也没用。

而nmcli device status则从NetworkManager视角看连接状态：

nmcli device status

输出中bond0的类型是bond，状态是connected；ens1f0和ens1f1的类型是ethernet，状态虽然显示connected，但实际上它们已经被标记为slave。

这三个命令组合起来，能快速定位是物理层、驱动层、还是配置层的问题。

3.5 重启验证：配置在重启后是否依然生效

很多bond配置在当时是好的，重启服务器之后就丢了或者起不来，这是因为连接没有设置开机自启。

检查所有连接的auto connect状态：

nmcli connection show bond0 | grep autoconnect nmcli connection show bond0-slave1 | grep autoconnect nmcli connection show bond0-slave2 | grep autoconnect

自动连接的值应为yes。如果显示no，说明新增连接的时候没有正确继承默认配置，需要手动开启：

nmcli connection modify bond0 connection.autoconnect yes nmcli connection modify bond0-slave1 connection.autoconnect yes nmcli connection modify bond0-slave2 connection.autoconnect yes

设置完之后，我习惯做一个完整的重启验证。重启前先备份配置目录：

cp -r /etc/sysconfig/network-scripts /root/network-scripts.bak

然后执行reboot，等系统起来后再次检查bond状态、IP地址、主备角色，确认全部跟重启前一致。

注意：重启前如果bond0连接依赖的物理网卡在启动阶段没有加载驱动，NetworkManager会等待网卡就绪再启动连接。如果你的物理网卡是第三方驱动（比如某些网卡需要额外装驱动），建议在grub里加载模块或者配置dracut带入驱动，否则重启后可能因为驱动加载顺序问题导致bond起不来。

4. 持久化与扩展配置：让Bond真正服务业务

4.1 配置多网段IP与VLAN的叠加玩法

一个bond0上只配一个IP是常规操作，但有些场景需要在一个bond上跑多个网段的业务，比如管理网一个IP，业务网一个IP。

只要IP地址之间不冲突，就可以在bond0连接上追加多个地址：

nmcli connection modify bond0 +ipv4.addresses 10.20.30.40/24

需要删除地址用减号：

nmcli connection modify bond0 -ipv4.addresses 10.20.30.40/24

然后重新up：

nmcli connection up bond0

如果业务网是通过VLAN划分的，那就在bond0之上创建VLAN子接口。使用nmcli创建VLAN连接也很简洁：

nmcli connection add type vlan con-name bond0.100 ifname bond0.100 dev bond0 id 100 ipv4.addresses 172.16.100.10/24 ipv4.method manual

创建之后启动连接：

nmcli connection up bond0.100

这个场景常见于虚拟化宿主机：物理服务器两三块网卡做成一个bond，然后上面挂几十个VLAN，分别给不同的虚拟机业务使用。用nmcli做这个整合操作非常顺手，只需要在bond0这个虚拟设备上不停创建VLAN子接口。

4.2 修改Bond模式时要注意的坑

有些同学配完mode1用了一段时间，想把链路改成mode4，然后直接修改bond0的选项：

nmcli connection modify bond0 bond.options mode 802.3ad nmcli connection up bond0

这么做不一定成功。原因在于bond模式切换影响链路连接状态，NetworkManager在bond0已经激活的状态下修改mode，底层bond设备会尝试重新协商，但某些驱动或网卡固件并不支持热切换。而且如果对端交换机没有同时配置LACP，mode4链路根本拉不起来。

正确做法是先断开bond：

nmcli connection down bond0 nmcli connection modify bond0 bond.options mode 802.3ad nmcli connection up bond0

如果断开后还是不行，需要把从属接口的连接也一并down掉，然后从逻辑上重建一次：

nmcli connection down bond0-slave1 nmcli connection down bond0-slave2 nmcli connection down bond0 nmcli connection modify bond0 bond.options mode 802.3ad nmcli connection up bond0 nmcli connection up bond0-slave1 nmcli connection up bond0-slave2

所以在生产环境里，bond模式的选择一定要提前想好，不要想着随便配完之后再切换。如果是上线新项目，我强烈建议在测试机把mode4交换机配合的问题先验证完，再考虑上生产。

4.3 使用Team作为替代方案值不值得

CentOS8里除了传统bond，还支持Team技术，它的设计初衷是比bond更灵活，支持更复杂的链路监测和故障恢复策略。

但实际深入使用后，我的结论是：传统bond就够用了，不必增加复杂度。Team的优势在于支持基于LACP的链路选择策略和更细粒度的端口监控，但它给运维带来的额外学习成本完全不值当。更重要的是，很多第三方工具（比如监控系统、网卡厂商管理软件）对Team的兼容性不如对bond好。

nmcli创建team的命令和bond非常像：

nmcli connection add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}' nmcli connection add type team-slave con-name team0-slave1 ifname ens1f0 master team0

但如果你不是对Team有明确需求，建议统一用bond路线，线上出了问题查文档也更方便。

4.4 把配置导出备份，做到心中有数

生产服务器上做任何网络改动，配置备份都是我们这一行的美德。nmcli本身没有专门的“导出”命令，但NetworkManager的配置最终会落盘在/etc/sysconfig/network-scripts目录。

用tar打包备份整个目录，随时可以恢复到配置变更前：

tar czvf /root/network-backup-$(date +%F).tar.gz /etc/sysconfig/network-scripts/

同时把bond的当前状态存档一份：

cat /proc/net/bonding/bond0 > /root/bond0-status-$(date +%F).txt

有了这份备份，就算在配置过程中出现误操作，也能快速恢复现场。

5. 踩坑实录与排查速查

5.1 问题一：bond0创建成功但IP配不上去

症状：执行nmcli connection up bond0之后，用ip addr show bond0看不到配置的IP地址。

排查步骤：先确认bond0连接里是否真的有IP配置。执行：

nmcli connection show bond0 | grep ipv4

如果ipv4.addresses为空，说明之前用modify修改ipv4地址时没生效。原因通常是NetworkManager配置更新的顺序问题，重新执行一次modify再up，一般能解决。

如果ipv4.addresses有值但接口上就是没有，大概率是bond0从属网卡里有一块没有正常注册。执行cat /proc/net/bonding/bond0，看看slave接口数量是不是两块，如果只有一块，说明有slave连接没有up。

解决办法是把所有连接都down掉再按顺序up：

nmcli connection down bond0 nmcli connection down bond0-slave1 nmcli connection down bond0-slave2 nmcli connection up bond0 nmcli connection up bond0-slave1 nmcli connection up bond0-slave2

5.2 问题二：mode4配置了但链路起不来

症状：配置mode4之后，cat /proc/net/bonding/bond0显示MII Status为up，但交换机侧查看LACP状态为Down，业务也不通。

这种情况十有八九是交换机没有配置LACP或者链路聚合模式不匹配。用mode4有一点必须清楚：需要把交换机对应的两个接口加入同一个Eth-Trunk，并且手工创建聚合组，而不是动态自动协商。

在华为交换机上的配置一般是：

interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan all mode lacp-static interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1

如果交换机是Cisco，则是：

interface Port-channel1 switchport mode trunk switchport trunk allowed vlan all interface GigabitEthernet0/1 channel-group 1 mode active interface GigabitEthernet0/2 channel-group 1 mode active

两边必须保持LACP配置一致。服务器端mode4，交换机端也要采用主动模式或者被动模式匹配上。

我这几年下来，发现mode4在国产交换机、H3C、华为、锐捷上兼容性还需要注意。有的厂商交换机在LACP协商中对LACPDU报文里的TLV字段要求苛刻，服务器网卡驱动版本不同也会影响协商结果。遇到这种问题，建议先去交换机查一下LACP的协商日志，再跟驱动版本对比排查。

5.3 问题三：重启后bond变成了非主备状态

症状：配置好mode1之后当时一切正常，但重启服务器后发现“Currently Active Slave”是ens1f1而不是预期的ens1f0。

原因：创建bond0时没有设置primary参数，或者primary指定的网卡在启动阶段比另一块网卡慢，内核选了一块可用链路作为主链路。

解决办法：创建bond时明确指定primary：

nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup primary ens1f0

如果bond0已经建好，可以修改选项：

nmcli connection modify bond0 bond.options "mode=active-backup,primary=ens1f0" nmcli connection down bond0 nmcli connection up bond0

注意bond.options这个属性名的写法，在nmcli里使用键值对方式设置。

另外，primary_reselect参数也会影响主备切换策略。默认是always，表示主网卡恢复后会自动切换回主；如果你希望让当前链路保持稳定，可以设置成better或failure。实际经验是：对低延迟敏感的业务，选择always；对稳定优先级高的业务，可以选择failure，避免主备频繁切换造成的抖动。

5.4 问题四：网卡命名不一致导致配置混乱

症状：服务器上物理网卡名一会儿是eth0、eth1，一会儿是ens1f0、enp2s0，配置bond时写错了名字，导致从属网卡根本没被加入。

原因：CentOS8默认使用一致性网络设备命名，接口名基于固件/PCI位置等信息生成，不稳定。如果之前装了其他系统或者改了biosdevname参数，名称更乱。

在配置时我习惯先执行：

ip link show

把所有网卡的真实名称列出来，确保ifname参数填对了。另外可以通过ethtool确认每块网卡对应的物理口：

ethtool -p ens1f0 3

执行后对应的物理网口指示灯会闪烁，这样就能确定哪块网卡在哪个槽位，避免把线插反了。

5.5 速查表：常用命令全集与用途

为方便日常运维，把CentOS8上用nmcli配置和管理bond的常用命令整理成速查表：

这张表可以直接截图贴到自己的运维手册里，遇到问题按表操作。

5.6 遇到奇奇怪怪的bond问题：先看日志再动手

有一类问题很让人抓狂：命令执行都正常，逻辑上也看不出毛病，但bond就是表现异常，比如丢包率高、切换速度慢、从属网卡状态一会up一会down。

这时候不要急着反复重启连接，先看内核日志：

journalctl -k | grep -i bond

以及NetworkManager的日志：

journalctl -u NetworkManager | grep -i bond

这两条命令会给出bond驱动上报的事件信息。比如我遇到过网卡固件bug导致bond切换时出现大量RX错误，日志里能明确看到网卡reset的字样，这时再检查网卡固件版本和驱动版本，找到是不是驱动bug导致。

有一次生产服务器出现偶发性断流，排查了很久，最后发现是mii监控间隔设置太短，导致物理网卡在瞬时抖动时被误判为链路故障，频繁切换引发网络丢包。这个问题的解决方式是调整miimon参数。

5.7 调整Bond监控和切换参数

bond的链路监控间隔和故障切换延迟都通过bond.options设置。默认的miimon为100ms，可以改成更长或者更短，但要根据场景权衡。

调整miimon到50ms：

nmcli connection modify bond0 bond.options "mode=active-backup,miimon=50,primary=ens1f0"

调整失败切换延迟：

nmcli connection modify bond0 bond.options "mode=active-backup,miimon=100,updelay=200,downdelay=200"

updelay表示链路恢复后在切换为主卡前的等待时间，避免因为网卡刚插上网线还处于不稳定状态时就切换过去导致业务又断一次。

我亲测的经验是：交换机上做了端口安全或者STP收敛的场景，如果updelay设置太小，主网卡恢复时STP状态还在learning，一切换过去直接黑十几秒。设置成300-500毫秒的updelay能有效避免这种情况。

最后的操作心得

CentOS8上做bond，本质就是跟NetworkManager打交道。顺着nmcli的语法推进，基本不会出大问题。如果实在遇到诡异现象，先不要怀疑命令错了，优先检查物理链路、交换机配置、驱动兼容性这三样。我在实际操作中最深的一点体会就是，bond不是配完就能撒手的，尤其是mode4，它依赖的交换机端配置必须同期对齐，两边只要有一边不一致，链路就起不来。另外建议每台服务器都留一份bond的配置备份，并记录好主板网卡槽位和物理口对应关系，后面做硬件更换或者交换机割接时能省掉很多扯皮时间。按照这份命令思路去部署和排查，你会在实际运维里少走很多弯路。