虚拟机bond网卡配置失败，绝大多数时候不是命令敲错，而是虚拟化层和系统层的配合出了问题，按顺序排查即可解决。
为什么虚拟机里的bond配置和老物理机不一样
不少人在物理机上配bond一次成功，换了虚拟机就翻车。 原因很简单：物理机的两张网卡直连交换机的两个物理口，而虚拟机的“网卡”只是虚拟化软件模拟出来的设备，后面可能还隔着一层虚拟交换机,这个差异直接决定了故障排查的方向。
虚拟网卡的“假多队列”陷阱
在VMware或者KVM环境里，给虚拟机添加两张网卡，它们的PCI地址、中断号、驱动加载顺序和物理机完全不同，如果直接在虚拟机里把eth0和eth1绑成bond0，系统本身没问题，但流量出口的行为和你预期可能不一样。行业共识认为，虚拟化平台默认就给每个虚拟网卡配了多队列，这时再叠加bonding的负载均衡算法,反而会造成乱序和丢包。
交换机侧看不到两个MAC是正常现象
虚拟机内部的bond配置完成后，你在物理交换机的端口上只会看到一个MAC地址，如果按照物理机的习惯去交换机上查两个MAC，查不到不代表配置失败，这个认知差，就是相当一部分“配置失败”误判的根源。
bond模式怎么选：主备还是负载均衡
虚拟化环境选bond模式，比物理机更需要克制。别一上来就mode 4,虚拟交换机未必支持LACP协商。
| 模式 | 物理机场景 | 虚拟机场景 | 失败概率 |
|---|---|---|---|
| mode 1（主备） | 求稳 | 最推荐 | 很低 |
| mode 4（LACP） | 需要交换机配合 | 依赖虚拟交换机设置 | 较高 |
| mode 6（负载均衡） | 无需交换机配合 | 可能造成包乱序 | 中等 |
如果你用的虚拟化平台是VMware ESXi，宿主机上的网卡绑定和虚拟机内部的bond是两个层面的事，多数情况下，虚拟机内部用mode 1就够了，两条链路一条用来跑业务，一条做热备，业务连续性不输给复杂的负载均衡模式，如果不是压测环境或者带宽确实不够，不要指望虚拟机里的mode 4能跑出多大性能提升。
虚拟机bond网卡配置失败？先查这5个常见原因
原因1：bonding模块根本没加载
这是最容易被忽视的一步，很多发行版默认不加载bonding内核模块，你光写了配置文件,重启网络服务直接报错。
检查方法：
lsmod | grep bonding
如果没有任何输出,先加载：
modprobe bonding
然后确认开机自动加载：
echo "bonding" >> /etc/modules-load.d/bonding.conf
这一步不做，后面全是白费。
原因2：NetworkManager在背后捣乱
现在的CentOS、Rocky Linux、Ubuntu Server默认都跑着NetworkManager，它会在你编辑完ifcfg文件重启网络时，自作主张把物理网卡的配置接管过去,导致bond0起不来。
处理方法有两种：
- 干脆禁用NetworkManager，回到network.service管理方式
- 用nmcli命令创建bond，让NetworkManager自己管理
如果你习惯改配置文件的方式,建议先停掉NetworkManager：
systemctl stop NetworkManager systemctl disable NetworkManager systemctl restart network
原因3：BONDING_OPTS参数写错位置
bond0的配置文件里有一个高频坑：把BONDING_OPTS写进了物理网卡的配置文件里,正确的是写在bond0的配置里。
正确姿势：
# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 BOOTPROTO=none ONBOOT=yes BONDING_OPTS="mode=1 miimon=100"
两个物理网卡配置里需要加上：
MASTER=bond0 SLAVE=yes
注意顺序：先启动bond0，再启动物理网卡，用systemctl restart network之前，最好看一下启动日志，有没有“SLAVE without MASTER”这类的报错。
原因4：虚拟交换机只允许一个MAC
VMware的标准交换机默认开启了MAC地址伪装，但有些安全策略会限制虚拟机使用多个MAC地址，KVM宿主机上的Linux bridge（比如virbr0）默认只学习第一个MAC,这就导致bond的两张网卡有一张拿不到流量。
业内有经验的运维指出，在Proxmox VE这类基于KVM的平台上，虚拟机内部做bond，需要在宿主机上把两个虚拟网卡都挂到同一个Linux bridge下，而且这个bridge不能开启独立的MAC过滤，如果还是不行，检查一下虚拟机的网卡类型建议用virtio而不是e1000,e1000网卡的驱动对bonding的兼容性不太好。
原因5：网卡驱动不支持bond特性
查看当前网卡用的什么驱动：
ethtool -i eth0
如果驱动不是由内核原生支持的，比如某些闭源的虚拟网卡驱动，bonding参数设置得再标准也白搭，这时候的解决方案是换一种网卡类型，在虚拟化平台里把网卡改成virtio或者vmxnet3,再做bond。
bond配置后网络不通怎么办：一套排查流程
配置完了但是ping不通，别急着怀疑配置,按下面的顺序一步步来。
第一步：确认底层物理链路的link状态
先看两个slave物理网卡是不是都up：
ip link show eth0 ip link show eth1
如果有网卡显示DOWN，检查虚拟机的网卡连接状态，是“已连接”还是“网线已拔出”的虚拟表现，很多时候虚拟化平台上虚拟机网卡没勾选“连接”选项,系统内部怎么折腾都没用。
第二步：看bond0是否成功聚合
cat /proc/net/bonding/bond0
重点看Current Active Slave是哪个，MII Status是否为UP，如果这里显示DOWN，说明bond层就没建立成功,回到上面的原因1和原因3去排查。
顺手看一眼系统日志：
dmesg | grep bonding tail -100 /var/log/messages
第三步：检查ARP和实际流量走向
当bond0看起来正常、但ping不通网关时，问题出在流量转发层面,用到两个命令：
arp -n tcpdump -i bond0 icmp
tcpdump输出能看到请求发出去了但没回应，就用tcpdump分别抓eth0和eth1的流量，看数据是不是都从同一个口走了，在mode 1模式下，如果数据从两个口都出去，说明配置其实还是有问题mode 1的机制就是同一时间只有一个口转发数据。
如果发现数据确实只在其中一个口跑，另一个口一直空闲，但就是ping不通，那检查虚拟化平台的网卡队列设置和虚拟交换机安全策略，把“MAC地址更改”和“伪传输”都允许一下。
从被动修到主动防：bond配置的验收标准
bond配置完成后，建议做一个半小时的稳定性观察,而不是看一眼通了就收工。
- 用
watch -n1 cat /proc/net/bonding/bond0持续观察主备切换状态 - 主动把活跃的物理网卡禁用一个（在平台上把网卡断开），观察流量是否无缝切换
- 检查
ethtool eth0 | grep Speed确认协商速率符合虚拟网卡上限
Linux内核文档（Documentation/networking/bonding.rst）里明确提到，miimon=100是推荐值，低于这个值可能导致误判链路状态，这个参数不要为了追求“快速切换”调太低，虚拟化环境中的网络抖动比物理机更频繁,太敏感反而造成频繁的主备切换。
Q&A：虚拟机bond网卡配置失败相关问题
Q：虚拟机里bond mode 4配置失败，真的是交换机的锅吗？
A：多数情况是的，mode 4依赖LACP协商，虚拟交换机如果不透传LLDP报文和LACP协商帧，虚拟机的bond口就只能在聚合口状态上等待，KVM环境中注意br0上是否开启了hairpin模式，VMware环境检查端口组的负载均衡策略是否设置为“基于IP哈希”，如果虚拟交换机不支持LACP，果断换成mode 1,稳定压倒一切。
Q：ESXi虚拟机网卡做bond后宿主机端口聚合方式有什么要求？
A：ESXi虚拟机内部的bond和宿主机网络配置是独立的两层，宿主机分布式交换机可以配置为链路聚合，但虚拟机内部的bond不会影响宿主机端口组的负载均衡策略，ESXi层面把两个上行链路加入同一个增强型多播聚合组时，才建议虚拟机内部用mode 4，否则保持默认的route based on originating virtual port即可。
Q：bond配置失败导致ssh断连，还有其他方式能连上服务器吗？
A：如果bond配置把管理网络搞挂了，通过虚拟化平台的控制台就能直接进入系统（比如VMware的Web控制台、KVM的virt-manager），不需要依赖网络，改配置文件的时候建议临时加上一个cron任务每5分钟把bond配置文件备份还原,防止手误后彻底失去控制台访问前的挽回窗口。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/657824.html
