服务器中bond0是指将多块物理网卡绑定成一个逻辑网卡,通过Linux bonding技术实现网络冗余或带宽扩展,bond0”是该逻辑网卡的默认名称。简单说,它就是服务器在操作系统层面把多张网卡“拧成一股绳”,对外表现为一块网卡,这个机制被广泛用于数据中心和云计算场景,目的是保证网络连接不因单块网卡故障而中断,或者让多块网卡共同分摊流量。
为什么服务器里会有bond0:从网卡不够用到链路聚合
单块网卡的两个天然短板
物理网卡再快也有物理极限,一块千兆网卡跑满也就1Gbps,万兆网卡虽然快,但价格和交换机的配套成本高,更麻烦的是,网卡一旦烧毁或线缆松动,业务立刻断连,行业共识认为,服务器级别的网络可用性至少要实现“单点故障不影响业务”,而bond0就是解决这两个问题的低成本方案。
bonding模式的原理和分类
Linux bonding支持多种模式,但服务器里最常见的只有三种,其他模式要么太冷门,要么根本不适用生产环境,你可以通过查看/proc/net/bonding/bond0这个文件来确定当前用的是哪种模式。
- mode 1(active-backup,主备模式):同一时刻只有一块网卡在工作,另一块闲置待命,这块工作网卡挂了,备用网卡自动顶上,切换时间通常在1秒以内,具体取决于交换机配置和ARP通告间隔,这种模式只提供冗余,不提升带宽。
- mode 4(802.3ad,动态链路聚合):网卡之间启用LACP协议,需要交换机配合开启LACP才能生效,多块网卡同时工作,既能提供冗余,也能把带宽叠加,比如两块千兆网卡聚合成一个2Gbps的逻辑链路。
- mode 6(balance-alb,自适应负载均衡):不需要交换机额外配置,出方向流量按哈希算法分摊到多块网卡,入方向流量通过ARP协商实现负载均衡,配置最简单,但在高并发场景下CPU占用会比mode 4偏高。
如何确认服务器是否用了bond0
登录服务器执行下面几个命令,一眼就能看出有没有bond0。
ip addr show bond0如果输出里有UP和LOWER_UP状态,说明bond0处于工作状态。ethtool bond0查看聚合速度和协商结果。cat /proc/net/bonding/bond0
显示当前活动网卡和备用网卡的信息。
如果服务器里有bond0但业务没走它,很可能是路由或网卡配置文件里没有把bond0设为默认网关所在的接口,这类问题在服务器IP更换之后特别常见。
配置bond0的完整流程:从网卡驱动到交换机配合
准备阶段:看清网卡和系统环境
先执行lspci | grep -i ethernet查看物理网卡型号,再用ethtool eth0确认每块网卡的速度和自协商状态,绝大多数情况下,bond0内的所有物理网卡必须使用相同的速率和双工模式,混插千兆和万兆网卡会出现丢包率飙升的诡异现象。
修改网卡配置文件(以CentOS/RHEL系列为例)
场景是一台双网卡服务器,物理网卡名为eth0和eth1,系统版本是CentOS 7.9。
先创建bond0的配置文件/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0 NAME=bond0 TYPE=Bond BONDING_MASTER=yes IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 ONBOOT=yes BOOTPROTO=static BONDING_OPTS="mode=4 miimon=100 xmit_hash_policy=layer3+4"
然后修改eth0和eth1的配置,把它们的IP信息全部去掉,只保留网卡归属:
# ifcfg-eth0 DEVICE=eth0 NAME=eth0 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes
eth1的配置除了DEVICE和NAME改成eth1之外,其他完全一样。
加载bonding内核模块
/etc/modprobe.d/bonding.conf里写入:
alias bond0 bonding options bonding mode=4 miimon=100
有些发行版(比如Ubuntu 20.04及以上)使用netplan,配置语法不同,但bond0这个名称依然是默认值,配置完后执行systemctl restart network(CentOS)或netplan apply(Ubuntu),再用ip a show bond0验证IP是否生效。
交换机端的配合细节
mode 4必须让交换机上的对应物理端口配置成Link Aggregation Group(LAG),并且两端模式必须一致,比如交换机端口配置成动态LACP,服务器的bonding mode就不能用mode=1或mode=6,很多新手配置bond0不成功,八成是交换机端口没做聚合,或者STP(生成树协议)没设边缘端口导致协商超时。

bond0的常见故障和排查套路
bond0显示down,但物理网卡都是UP
这种场景经常出现在服务器重启之后,首先执行ip link set bond0 up手动拉起,再看cat /proc/net/bonding/bond0,如果显示MII Status: down,说明物理网卡和 bond0 之间的关联丢了,可以用ip link set eth0 master bond0重新绑定,更彻底的做法是检查/etc/sysconfig/network-scripts/下是否有其他网卡配置文件把eth0单独设置了IP,存在这种文件的话优先级会覆盖bond0的设置。
bond0通了,但实际带宽没有翻倍
mode 4虽然聚合了多块网卡,但单条TCP连接只能使用其中一块网卡,流量分发是按哈希算法计算的,哈希因子默认是源IP、目的IP、源端口、目的端口的组合,如果你的业务只和少数几个IP通信,流量很可能全打在同一个物理网卡上,排查方法是用ethtool -S eth0和ethtool -S eth1分别看两个网卡的收发流量,如果一边飙满一边闲着,说明哈希策略不适合当前业务,这时候换xmit_hash_policy=layer3+4或者用多个并发连接测试,通常能缓解。
网关不在bond0上
有些场景下服务器有多个网卡绑定到不同bond接口(比如bond0走业务,bond1走管理),如果默认路由指向 bond0,但业务系统只监听 bond1 的IP,访问就会超时。ip route show看一下默认路由指向哪个接口,如果不是bond0,用ip route replace default via 网关IP dev bond0临时修正,持久化需要改/etc/sysconfig/network-scripts/route-bond0文件。
什么场景下不建议使用bond0
虚拟化平台的分布式交换机环境
在VMware ESXi或KVM虚拟机里,宿主机层面的bond0和虚拟机网卡的bonding机制会互相干扰,比如虚拟机内部再做一次绑定,可能出现MAC地址漂移导致广播风暴,业内专家指出,这种情况下物理网卡做bond0即可,虚拟机内部应保持普通网卡模式。
跨交换机部署bond0的复杂度
如果两块物理网卡分别接到两台不同的交换机,必须配置堆叠或VPC(虚拟端口通道)才能实现跨设备聚合,没有堆叠的环境里,建议老老实实用mode 1主备模式,别用mode 4,两台中低端交换机各自独立运行stp,跨设备聚合会导致某个端口被block,业务直接断开,这也是

bond0高可用方案里最容易踩坑的地带。
Q&A:关于bond0的高频疑问
我刚刚买的简米云服务器里能看到bond0吗?这和我本地机房的bond0有什么区别?
简米云的经典网络和VPC环境中,云服务器默认使用的是虚拟化网络,不会暴露bond0给用户,你执行ip addr show bond0大概率看不到这个接口,因为宿主机层面的网卡绑定已经在虚拟交换机上完成了,本地机房的物理服务器做bond0,操作的是真实的物理网卡和物理交换机,两者配置逻辑完全不同,所以如果你在ECS实例里搜索bond0相关配置,可能一无所获这在云服务器价格战中尤其容易让新手误以为自己买到了“缺网卡”的机器。
bond0和team0哪个更值得长期使用?
team0是Red Hat推出的网络组(team)方案,设计目标是用独立的teamd服务做网卡绑定,支持的负载均衡算法比bonding更细,但近年来Red Hat官方已经明确推荐使用bonding,teamd从RHEL 9开始被标记为弃用,行业共识认为,新部署的服务器应直接使用bond0,不必再考虑teamd,因为社区维护重心早已回落到bonding驱动上。
bond0配置完成后,如何确认故障切换真的有效?
拔线测试是最直接的方法,先让一台服务器持续ping网关地址,然后依次拔掉bond0里的第一块物理网卡网线,观察ping丢包情况,如果切换正常,丢失的包数应该只有1到2个,这对应MI(媒体独立接口)监控间隔内的切换延迟,命令执行过程中用watch -n 1 cat /proc/net/bonding/bond0观察活动网卡是否从eth0切换到了eth1,如果丢包超过5个,尝试把miimon从100降到50,但注意太低的miimon值会占用更多CPU,测试完毕后插回网线,查看链路是否回切mode 1默认不回切,mode 4则会重新计算聚合组成员。
bond0本质上是Linux系统里的一层逻辑网络设备,它的价值在于用低成本硬件换来高可用和可扩展的带宽,实际运维中,准确判断自己需要的模式、验证两端配置一致性、并熟练使用/proc/net/bonding/bond0进行状态排查,就是掌握bond0的三个关键能力,服务器网络是业务命脉,bond0不是万能药,它需要一个诚实而细致的运维者配合。
图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/796830.html


评论列表(5条)
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于行业共识认为的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!
这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是行业共识认为部分,给了我很多新的思路。感谢分享这么好的内容!
@老happy6973:读了这篇文章,我深有感触。作者对行业共识认为的理解非常深刻,论述也很有逻辑性。内容既有理论深度,又有实践指导意义,确实是一篇值得细细品味的好文章。希望作者能继续创作更多优秀的作品!
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于行业共识认为的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于行业共识认为的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!