在虚拟化环境里给一台 CentOS 虚拟机配双网卡绑定乍一看是个十分钟就能收工的活但真到动手的时候坑往往出在你想不到的地方虚拟交换机不认 LACP、从接口抢了主接口的 IP、NetworkManager 和你手写的 ifcfg 文件互相打架、重启之后 bond0 名字变成了别的。这篇就把“VMware 里 CentOS 系统下使用 Bonding 技术实现两块网卡绑定”整套流程拆开讲透从模式选型、内核模块、配置文件到故障切换验证把我自己踩过的坑和绕过的弯都摆出来。适合手上正好有一台多网卡虚拟机要做冗余或吞吐叠加的同学也适合刚接触 Linux 网络配置、想弄明白 bonding 到底在干什么的朋友。看完你应该能独立把一套 active-backup 或 802.3ad 的绑定跑起来并且知道为什么某些模式在你的虚拟化平台上注定跑不出预期效果。1. 为什么要在虚拟机里折腾网卡绑定1.1 先搞清楚你要的是冗余还是吞吐网卡绑定Bonding也常被称为链路聚合、网卡 teaming在 Linux 内核里做的其实是一件很朴素的事把多块物理或虚拟网卡在逻辑上合并成一个接口由内核的 bonding 驱动统一调度收发。但“合并”这两个字背后藏着两种完全不同的目标选型时必须先想明白自己属于哪一类。第一类是冗余。典型场景是这台虚拟机上跑着一个对外提供服务的进程你不希望某一块虚拟网卡断开宿主机网卡故障、虚拟交换机上行链路切换、运维误操作之后业务直接失联。这类需求对应的是 active-backup 模式同一时刻只有一块网卡在工作另一块待命主链路断了立刻顶上。第二类是吞吐。你希望两块网卡同时发包把上行带宽叠加起来或者至少让多路流量分摊到不同的物理链路上。这类需求对应的是 balance-rr、balance-xor、802.3ad 等模式。但这里有个非常关键的前提虚拟机内部的“两块网卡”并不等于物理世界里的两条独立链路。如果这两块虚拟网卡在宿主机上接到的是同一个虚拟交换机、走的是同一块物理网卡上行那么无论你在虚拟机里怎么绑物理出口的带宽上限一点都不会变。我在早期项目里就干过这种傻事一台虚拟机加了四块网卡配了 balance-rr用 iperf3 一测速度确实翻了几倍兴高采烈地汇报说链路聚合生效了。后来才发现两台虚拟机都在同一台宿主机上、接同一个虚拟交换机流量压根没出物理网卡测出来的是内存拷贝速度。换到跨物理主机一测立刻打回原形。所以动手之前先在纸上画清楚宿主机有多少块物理网卡虚拟交换机挂了几条上行你要聚合的两块虚拟网卡是不是落在不同的上行链路上1.2 Bonding 的七种模式虚拟化环境里能用的其实没几个Linux bonding 驱动一共提供七种工作模式编号 0 到 6配置文件里用mode指定。很多人图省事直接抄网上的例子写mode6或者mode4结果发现根本不工作原因就在于这些模式对底层网络设备有硬性要求而虚拟网卡未必满足。模式编号名称是否需要交换机配合带宽是否叠加虚拟化环境适用性0balance-rr 轮询否是一般易乱序1active-backup 主备否否最稳首选2balance-xor 异或是静态聚合是需交换机配置3broadcast 广播否否特殊场景才用4802.3ad 动态聚合是必须 LACP是标准虚拟交换机上基本废5balance-tlb 自适应发送否部分依赖网卡驱动支持6balance-alb 自适应负载否部分依赖网卡改 MAC 能力模式 4802.3ad是很多人心里的“标准答案”因为它能真正和交换机协商出聚合组带宽叠加、故障切换都规范。但它的前提是对端交换机必须支持并开启 LACP。VMware 的标准虚拟交换机vSwitch不支持 LACP只有分布式交换机配合 LAG 才行。也就是说如果你的虚拟机接的是普通的 vSwitch 端口组配成 mode4 之后虚拟机这边会一直发 LACPDU交换机侧毫无反应bond 状态会卡在协商阶段最后可能只有一块网卡处于 up 状态另一块永远起不来。模式 5 和模式 6 依赖网卡驱动支持ethtool修改 MAC 地址和调整发送队列。VMXNET3 这类半虚拟化网卡在这方面的行为并不总是一致实测中经常出现 mode6 起得来但负载根本不均衡或者直接报错说无法修改硬件地址。真要用得先确认你的网卡类型。综合下来在 VMware 的虚拟化环境里active-backupmode1是性价比最高的选择配置简单、不依赖交换机、切换可靠。如果确实需要吞吐叠加再考虑配合分布式交换机做 LAG或者退一步用 balance-xor 让交换机配静态聚合。1.3 虚拟化层面对 bonding 的三个隐形约束除了模式选择虚拟化环境还额外加了三道枷锁这三条在纯物理机文档里基本看不到但恰恰是虚拟机里最容易翻车的地方。第一道是端口组的安全策略。VMware 的虚拟交换机无论是标准交换机还是分布式交换机在端口组上有三个安全选项混杂模式、MAC 地址更改、伪传输。默认策略通常是“拒绝”。bonding 的模式 1、2、4 都不会修改源 MAC所以不受影响但模式 6 会把发出的帧源 MAC 改成当前活动网卡的 MAC这时候如果“MAC 地址更改”被拒绝虚拟交换机会直接丢弃这些帧表现就是绑定看起来成功了但网络完全不通。第二道是上行链路的实际拓扑。前面已经提过虚拟机里的两块网卡如果最终汇聚到宿主机同一块物理网卡那么带宽叠加是假的、故障切换也是假的——物理网卡一挂两块虚拟网卡同时断。真正有意义的冗余要求两块虚拟网卡分别落在不同的物理上行、甚至不同的物理交换机上。这一点在规划阶段就要和负责虚拟化平台的同事确认清楚别等配完了才发现两条腿站在同一条船上。第三道是虚拟网卡的链路状态感知。bonding 判断链路是否可用靠的是 MII 状态监测miimon或者 ARP 探测。虚拟网卡在宿主机侧断开比如在虚拟机设置里取消勾选“已连接”时MII 状态会正确翻转bonding 能感知到但如果故障发生在物理交换机那一侧、而宿主机网卡仍然保持 link up虚拟机这边的虚拟网卡状态不会变此时只能靠 ARP 监测arp_intervalarp_ip_target来兜底。这也是为什么生产环境里我一般会把miimon和arp_interval一起配上。2. 动手之前的准备工作2.1 虚拟机侧网卡、虚拟交换机与端口组准备工作从虚拟机配置开始。先把虚拟机关机在虚拟硬件设置里添加第二块网络适配器。适配器类型优先选VMXNET3它是半虚拟化驱动性能最好而且在 CentOS 7 及以上版本里内核自带驱动开箱即用。E1000e 也能用但吞吐和 CPU 开销都不占优势。两块网卡接到哪里取决于你的目标。如果只是做冗余演练接到同一个虚拟交换机的同一个端口组就可以如果要做真实的链路冗余需要把它们接到不同的端口组而这两个端口组的上行分别绑到不同的物理网卡。端口组的安全策略要按前面说的检查一遍确认“MAC 地址更改”和“伪传输”在需要时被设为“接受”“混杂模式”在需要抓包或某些模式下也要放开。开机进系统之后第一件事是确认网卡被正确识别。ip link show或者nmcli device status都能看到接口列表。CentOS 7 之后网卡命名规则从 eth0、eth1 变成了 ens33、ens34 或者 ens192、ens224 这类基于固件信息的可预测命名。这个名字在后续所有配置文件里都要用到抄错一个字后面全盘皆输所以我习惯先把它们记在便签上。ip -br link show输出大概长这样lo UNKNOWN 00:00:00:00:00:00 LOOPBACK,UP,LOWER_UP ens33 UP 00:0c:29:aa:bb:cc BROADCAST,MULTICAST,UP,LOWER_UP ens34 UP 00:0c:29:aa:bb:dd BROADCAST,MULTICAST,UP,LOWER_UP两块网卡都处于 UP 状态、都有独立的 MAC 地址这是后续操作的前提。如果第二块网卡显示 DOWN 或者压根没出现先回虚拟机设置里检查是否勾选了“打开电源时连接”有些模板机默认是断开状态。2.2 系统侧确认系统版本与网络管理方式CentOS 7 和 CentOS 8 在网络管理上有一个不小的分水岭配置方式完全不同所以动手前必须先确认版本和当前生效的网络管理服务。cat /etc/centos-release systemctl status NetworkManager --no-pager systemctl status network --no-pagerCentOS 7 默认同时装着network和NetworkManager两套服务实际生效的通常是network取决于安装时的选项NetworkManager处于停止或未启用状态。CentOS 8 则已经彻底移除传统的network服务所有配置必须走 NetworkManager/etc/sysconfig/network-scripts/下的 ifcfg 文件虽然还认但已经不再是主推方式。这个区别非常要命。我见过太多次“配完 ifcfg 文件重启网络没生效”的案例最后查出来是 NetworkManager 在管着网卡它压根不读你手写的那几个文件或者读了但用自己缓存的配置覆盖掉。判断方法很简单把网卡断开再重启网络服务看nmcli connection show里有没有对应的连接。我的建议是CentOS 7 用 ifcfg 文件方式务必先停用并禁用 NetworkManagerCentOS 8 及以上直接用 nmcli 命令别再去手写 ifcfg。两套方式不要混用混用的下场就是配置飘忽不定重启十次可能有两次结果不一样。2.3 先把规划表填满别边配边想动手写配置之前把下面这张表填清楚后面的操作基本就是照抄。我每次做这类配置都会先在文本里把表列出来配完再对照检查一遍这比事后排查省太多时间。项目示例值说明bond 接口名bond0不能与已有接口重名绑定模式mode1active-backup监测间隔 miimon100单位毫秒100ms 检测一次主网卡 primaryens33仅 active-backup 模式有效从接口ens33、ens34必须都未配置 IPbond0 IP192.168.100.10/24静态地址网关192.168.100.1与 IP 同网段DNS192.168.100.1按实际环境填这张表里最容易被忽略的是“从接口必须未配置 IP”。如果 ens33 原本带着 IP 地址你把它加成 bond0 的从接口那个 IP 会一直挂在 enslave 的接口上跟 bond0 抢路由表现就是网络时通时不通、或者干脆不通。所以第一步是把原有网卡的 IP 配置清掉只保留BOOTPROTOnone和ONBOOTyes。3. 核心配置流程逐条拆解3.1 加载 bonding 内核模块并保证开机自启bonding 驱动是以内核模块形式存在的虽然大多数发行版的内核已经把它编译进去了但仍然需要一个“触发”动作让内核在启动网络之前就把 bond0 这个逻辑接口的骨架建出来。做法是在/etc/modprobe.d/下写一个配置文件。vi /etc/modprobe.d/bonding.conf内容alias bond0 bonding options bond0 miimon100 mode1 primaryens33这里的options行很关键。它决定了 bond0 被创建时的默认参数。很多人习惯把BONDING_OPTS写在 ifcfg-bond0 里这在 CentOS 7 上是有效的但如果模块参数和 ifcfg 参数写得不一致最终以哪边为准要看加载顺序很容易出现“我明明改成了 mode4怎么还是 mode1”的诡异现象。我的做法是两边写一致modprobe 配置里写一遍保证模块加载时参数正确ifcfg 里再写一遍保证接口配置自洽。写完之后手动加载并验证modprobe bonding lsmod | grep bonding cat /sys/class/net/bonding_masters如果bonding_masters里为空说明模块已加载但还没有创建具体的 bond 接口这是正常状态下一步配置 bond0 时会自动创建。提示如果系统上已经有别的 bond 接口比如 bond1bonding_masters里会列出来。此时不要再往options里塞第二个alias因为模块参数是全局的多个 bond 接口共用同一批 options需要单独配置的得靠 ifcfg 里的BONDING_OPTS。3.2 编写 bond0 主接口配置文件CentOS 7 的 ifcfg 文件放在/etc/sysconfig/network-scripts/。bond 主接口的文件名是ifcfg-bond0内容比普通网卡多几个专用字段。vi /etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOnone IPADDR192.168.100.10 PREFIX24 GATEWAY192.168.100.1 DNS1192.168.100.1 ONBOOTyes BONDING_OPTSmode1 miimon100 primaryens33 updelay0 downdelay0几个字段值得单独说明。TYPEBond和BONDING_MASTERyes是告诉网络初始化脚本“这是一个 bond 主接口”缺了TYPE有的版本会把它当普通以太网处理bonding 驱动不会被正确挂上去。BONDING_OPTS里的参数会通过 sysfs 写入/sys/class/net/bond0/bonding/下的各个文件所以它支持所有 bonding 模块参数。primaryens33只在 mode1 下有意义作用是优先使用 ens33 作为活动链路ens34 作为备份。为什么要指定 primary因为在 active-backup 模式下如果某条链路反复抖动内核可能会在两条链路之间来回切换导致 MAC 地址频繁变化、上层连接被打断。指定一个稳定的 primary可以让切换行为可控一些。如果不指定bonding 会选第一个 up 的从接口作为活动口这个顺序和内核探测顺序有关不保证每次都一样。updelay和downdelay是链路状态变化的防抖参数单位毫秒。updelay表示链路从 down 变 up 之后要等多久才真正启用它防止链路抖动造成的频繁切换downdelay是反过来链路 down 之后等多久才确认它真的挂了。这两个值在虚拟环境里我一般设为 0 或很小的值因为虚拟网卡的 link 状态翻转非常干脆不像物理网卡那样有光模块握手延迟。3.3 从接口配置只做“哑巴”不配地址两块从接口的配置文件要把原来的 IP 全部拿掉改成 master/slave 关系。vi /etc/sysconfig/network-scripts/ifcfg-ens33DEVICEens33 NAMEens33 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyesifcfg-ens34同理只是把DEVICE和NAME换成 ens34。这里唯一不能少的是MASTER和SLAVE两行网络初始化脚本靠它们判断这个接口属于哪个 bond。BOOTPROTOnone也很重要如果写成dhcp接口在 enslaved 之前会尝试获取地址可能造成延迟甚至失败。有一个细节从接口上如果还残留着原来的IPADDR、GATEWAY、DNS1等字段一定要删干净。我遇到过一种情况从接口残留了GATEWAY结果每次重启后默认路由会从 bond0 变成 ens34ip route里看到的是default via 192.168.100.1 dev ens34而 ens34 在 enslavement 之后是没有 IP 的路由直接失效。这种问题排查起来很费时间因为表面症状是“bond0 有 IP 但上不了网”。配完之后重启网络服务systemctl stop NetworkManager systemctl disable NetworkManager systemctl restart network注意systemctl restart network在某些 CentOS 7 版本上会先 down 掉所有接口再 up如果操作是通过 SSH 远程进行的连接会断掉。稳妥的做法是配置完先systemctl restart network时准备好控制台访问或者用nmcli热加载。我个人的习惯是本地控制台操作这类底层网络变更远程操作只做读取验证。3.4 用 nmcli 的替代写法与两种方式的取舍CentOS 8 及以后没有network服务只能走 NetworkManager。这个时候 nmcli 命令反而更顺手因为它支持一条命令对象化配置不需要记文件路径和字段名。nmcli connection add type bond con-name bond0 ifname bond0 \ mode active-backup miimon 100 primary ens33 \ ipv4.method manual ipv4.addresses 192.168.100.10/24 \ ipv4.gateway 192.168.100.1 ipv4.dns 192.168.100.1 \ connection.autoconnect yes nmcli connection add type ethernet con-name bond0-slave1 ifname ens33 \ master bond0 connection.autoconnect yes nmcli connection add type ethernet con-name bond0-slave2 ifname ens34 \ master bond0 connection.autoconnect yes nmcli connection up bond0这套命令的好处是原子性比较好每条命令执行完立刻体现在 NetworkManager 的配置里不需要重启服务。缺点是名字容易记混con-name和ifname是两个概念——con-name是连接的显示名ifname是实际的网络接口设备名两者可以不同但最好保持一致不然以后看nmcli connection show会一脸懵。两种方式的取舍很简单你的系统上哪个服务在管网络就用哪种方式。判断方法是systemctl is-active NetworkManager和systemctl is-active network。如果两个都 active那就是高危险状态必须先关掉一个再动配置否则你改了 AB 可能在下次重启时把配置改回去。4. 验证、压测与故障切换实测4.1 三层检查法接口层、bonding 层、网络层配置完成之后不要急着测业务先按三个层次依次确认。第一层看接口本身第二层看 bonding 驱动的状态第三层才是 IP 和路由。接口层ip -br link show期望看到bond0处于 UP 状态ens33和ens34也是 UP 但NO-CARRIER 这一项不出现同时它们的master bond0标识会体现在ip link的详细信息里。bonding 层cat /proc/net/bonding/bond0这个文件是排查 bonding 问题的第一现场输出大致如下Bonding Mode: fault-tolerance (active-backup) Primary Slave: ens33 (primary_reselect always) Currently Active Slave: ens33 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: ens33 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:0c:29:aa:bb:cc Slave queue ID: 0 Slave Interface: ens34 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:0c:29:aa:bb:dd Slave queue ID: 0重点看三处Bonding Mode是否和配置一致、Currently Active Slave是哪块、每个从接口的MII Status是否都是 up。如果某个从接口显示down先去看Link Failure Count这个计数在每次链路翻转时会加一能帮你判断是配置问题还是链路问题。网络层ip addr show bond0 ip route show ping -c 4 192.168.100.1ip route里默认路由必须指向 bond0如果指向 ens33 或者 ens34说明从接口上还有残留配置回去清理。4.2 亲手制造一次链路故障看切换是否真的发生bonding 配好了不代表切换就一定能工作必须主动制造故障验证。在 VMware 环境下最干净的模拟方式是在虚拟机设置里取消勾选当前活动网卡的“已连接”这等价于物理拔线。操作之前先开一个持续 ping 的窗口ping 192.168.100.1然后在虚拟机设置里断开 ens33也就是 primary观察两件事ping 是否中断、/proc/net/bonding/bond0里Currently Active Slave是否变成了 ens34。在 mode1、miimon100 的配置下正常表现是丢 1 到 2 个包切换在 200 毫秒内完成。如果丢包持续十几秒甚至完全断掉那就要查原因了。最常见的是从接口根本没有被正确 enslave——cat /proc/net/bonding/bond0里只有一条 Slave Interface那不管断哪块都切不过去。再补充一个虚拟化环境特有的验证方式用ethtool看链路状态。ethtool bond0 ethtool ens33ethtool bond0的Speed字段在 active-backup 下显示的是当前活动网卡的速率切换之后会跟着变。这个可以作为辅助判断比翻/proc文件快。4.3 带宽测试的正确姿势与常见误判如果配的是负载均衡模式肯定想验证一下带宽是否真的叠加。这时候最容易犯的错就是在同一台宿主机上的两台虚拟机之间跑 iperf3测出来的数字漂亮得离谱但毫无参考价值。正确的测试拓扑应该是一台虚拟机在宿主机 A另一台在宿主机 B两者之间经过物理交换机和真实的上行链路。测试命令# 服务端 iperf3 -s # 客户端多流并发 iperf3 -c 192.168.100.20 -t 30 -P 4-P 4表示开 4 条并发流。为什么要多流因为 balance-xor、balance-tlb 这类模式的负载均衡是基于哈希算的单条 TCP 流的源目 IP 和端口固定哈希结果也固定永远只会走同一条链路带宽不会叠加。只有多流并发才能让不同的流哈希到不同的从接口上。这是判断“聚合到底有没有生效”的关键测试方法。对 active-backup 模式来说带宽测试的结果就是单链路带宽不要指望翻倍——它的价值在冗余不在吞吐。如果你测出来比单网卡还慢那可能是miimon设得太小导致频繁检测占用 CPU或者primary指定的网卡性能较差。还有一个容易误判的点虚拟交换机内部的转发带宽。同一端口组内两台虚拟机通信数据不经过物理网卡走的是宿主机内存此时 iperf3 能跑出 20Gbps 甚至更高的数字这个数字跟物理上行带宽没有任何关系。看到这种结果不要高兴先确认测试路径。5. 踩坑记录与常见问题速查5.1 VMware 侧的高频坑第一个坑mode4 配了但不通。前面已经说过标准虚拟交换机不支持 LACP。判断方法很简单看/proc/net/bonding/bond0里的Bonding Mode是否显示为IEEE 802.3ad Dynamic link aggregation同时看LACP rate和从接口状态。如果从接口一直是down或者只起来一个八成就是交换机侧没协商。解决办法只有两个换成 mode1或者把虚拟网络升级到支持 LAG 的分布式交换机。第二个坑mode6 起来但网络不通。这是端口组安全策略导致的。balance-alb 会把发出的帧源 MAC 改成当前活动网卡的 MAC而虚拟交换机默认拒绝“MAC 地址更改”。表现是 bond0 能起来、ip addr有地址但 ping 网关不通。解决办法是把端口组的“MAC 地址更改”和“伪传输”都设为接受。不过我一般建议直接换 mode1改安全策略在共享环境里可能影响其他虚拟机风险不小。第三个坑虚拟机迁移后 bonding 异常。虚拟机在不同宿主机之间迁移比如手动迁移或负载均衡触发的自动迁移时虚拟网卡的 PCI 位置、MAC 地址可能发生变化。如果/etc/modprobe.d/bonding.conf里硬编码了primaryens33而迁移后网卡名变了bond0 会找不到主接口退化成不指定 primary 的状态。这在跨版本、跨硬件平台的迁移里更容易出现。我的做法是 primary 参数尽量不写死或者用 udev 规则先把网卡名固定下来。5.2 CentOS 侧的高频坑坑一重启后 bond0 消失。最常见的原因是ONBOOT没设成 yes或者BONDING_MASTER字段缺失。另一个隐蔽原因是/etc/modprobe.d/bonding.conf的文件名不规范——有些老版本只认.conf后缀的特定文件名写成了bond.conf.bak之类的就不会被读取。坑二NetworkManager 和 network 打架。症状是改完 ifcfg 重启网络ip addr里 IP 变了但过一会儿又变回去或者 bond0 的配置时有时无。根因就是两套服务同时在跑各自维护自己的配置副本。解决办法是二选一停掉不用那个并disable别只是stop否则下次重启又会起来。坑三从接口 enslave 失败报Device or resource busy。通常是因为从接口上还有 IP 地址或者被别的服务占用比如 firewalld 的某个 zone 绑定了接口。处理顺序是先ip addr flush dev ens34清掉地址再ip link set ens34 down然后重启 network 服务。坑四BONDING_OPTS修改后不生效。bonding 的很多参数只能在接口 down 的状态下修改直接改 ifcfg 再restart network有时候不会重新加载模块参数。彻底生效的方法是ip link set bond0 down然后重新 up或者干脆重启系统。要在线改参数可以直接写 sysfsecho 200 /sys/class/net/bond0/bonding/miimon但不是所有参数都支持在线改mode就要求接口必须先 down。5.3 常见问题速查表现象可能原因排查动作解决方式bond0 起不来无 bonding 模块配置lsmod | grep bonding补/etc/modprobe.d/bonding.confbond0 无 IP从接口残留 IP 抢占ip route show看默认路由指向清理从接口的 IPADDR/GATEWAY只有一块网卡在 bond 里从接口未 enslavecat /proc/net/bonding/bond0检查 MASTER/SLAVE 字段切换后完全断网另一块网卡本身不通单独给 ens34 配临时 IP 测试检查虚拟交换机端口组带宽没有叠加单流哈希固定用-P 4多流测试改 xmit_hash_policy 为 layer34重启后配置丢失ONBOOT 未开启grep ONBOOT ifcfg-*改为 yesmode4 不通交换机不支持 LACP查看 LACP 协商状态换 mode1 或升级分布式交换机mode6 不通端口组拒绝 MAC 更改看虚拟机网络策略放开 MAC 地址更改或换 mode5.4 几条不写在文档里的经验第一xmit_hash_policy这个参数值得单独调。默认是layer2只按源目 MAC 算哈希在虚拟机环境里 MAC 数量少很容易所有流都撞到同一条链路。改成layer34之后按 IP 和端口算分布均匀得多。配置写法是在BONDING_OPTS里加xmit_hash_policylayer34。注意这个参数对 mode1 无效只影响负载均衡类模式。第二从接口的Speed和Duplex在虚拟网卡上基本没有参考价值。VMXNET3 报告的速率往往是个虚值比如 10000 Mbps跟真实带宽没关系。不要拿这个判断链路质量老老实实用 iperf3 压测。第三做变更之前先备份/etc/sysconfig/network-scripts/整个目录用cp -a保留属性。虚拟机做快照当然更省事但如果虚拟机没条件打快照目录备份就是最后的保险。我遇到过一次 bond0 配置写错导致远程连接彻底断掉最后靠控制台进去从备份目录恢复五分钟解决如果没有备份可能就得重装系统了。第四日志里藏着很多线索。journalctl -u network --no-pager -n 100和dmesg | grep -i bond这两条命令在排查时非常好用网络服务的报错信息往往比/proc里的状态更直白。6. 一个真实的调试过程与后续扩展思路说一个我印象比较深的排查过程。有台虚拟机配了 active-backup/proc/net/bonding/bond0显示两个从接口都是 upCurrently Active Slave是 ens33看起来一切正常。但业务方反映偶尔会丢几个包一天大概出现两三次。我一开始怀疑是miimon太大的问题从 100 调到 50 也没解决。后来在Link Failure Count上发现了端倪两个从接口的计数一直在缓慢增长。这说明链路在频繁地短暂中断又恢复但因为updelay0每次恢复后立刻切回去切换瞬间丢包。根源在于宿主机上那块物理网卡的链路有轻微抖动虚拟交换机把这种抖动透传到了虚拟机里。解决方式很土但有效把updelay设成 500downdelay设成 200给切换加上防抖窗口。改完之后Link Failure Count还在涨但业务侧的丢包消失了因为短暂的抖动被防抖参数吸收掉了没有触发真正的切换。这个案例说明遇到偶发丢包时先看计数器别急着改配置。计数器增长本身就是最有力的线索。至于后续的扩展方向如果这套 bond 是为了跑需要高可用的服务可以在这之上再做一层 keepalived 或者 corosync让两台虚拟机的 bond 接口组成主备关系覆盖单机整机故障的场景。bonding 解决的是网卡级别的冗余主机级别的冗余得靠上层方案两者不冲突可以叠着用。另外如果环境里有条件上分布式交换机把标准 vSwitch 换成 dvSwitch 并配置 LAG就能真正用上 802.3ad 的动态聚合那时候xmit_hash_policy调优才有意义——标准交换机下的静态聚合哈希配置再精细也没法跟 LACP 的协商能力比。