干运维这些年半夜被电话叫起来处理网络故障十次里得有七八次和网卡绑定有关。刚入行的时候我总以为 bond 就是把几块网卡捆在一起提升速度直到有一次在业务高峰期把核心数据库的网络绑得近乎瘫痪才老老实实把 Linux bonding 的原理和每种模式的脾气摸了一遍。这篇小记算是我个人的实践笔记写给要处理物理机双网卡 bonding 的运维同行也写给刚接触 Linux 网络基础的朋友。Bond 这个功能在 Linux 内核里已经存在二十多年了简单说就是把多块物理网卡聚合成一块逻辑网卡对外暴露同一个 IP对内按算法把数据流分到不同的物理链路。听着不复杂但具体用哪种模式、交换机端怎么配合、虚拟化环境怎么处理里面坑特别多。我先把适用范围说清楚如果你是在物理服务器上做链路冗余或者刚接触 Linux 网络配置又或者总在虚拟机环境里被网卡问题绕晕这篇内容应该能给你省点弯路如果你对 bond 已经很熟可以直接跳到第 3 节看配置或者到第 4 节看踩坑记录。1. 先弄明白 Bond 这件事的本质1.1 它解决的是单点故障不只是带宽很多朋友听说 Bond 第一反应是“带宽翻倍”这个理解其实只对了一半。Bond 最早解决的是链路单点故障问题一块物理网卡、一根网线、交换机一个端口任何一个环节出问题业务就断了。服务器如果跑的是数据库、存储节点、虚拟化宿主机断一次网带来的可能就是长时间业务中断甚至集群脑裂。把两块网卡做成主备关系后物理链路挂了可以在秒级自动切到另一条这才是 Bond 最核心的价值。至于带宽叠加要看具体模式。最简单粗暴的 balance-rrmode 0会把数据包轮流从多块网卡发出去理论上两块千兆卡能跑满 2Gbps但实际上对端交换机如果没有做相应的链路聚合数据包可能走不同的物理路径到达接收侧重排数据包的负担会很大表现就是速度不但没提升反而丢包、乱序。网络传输不是两根水管直接并在一起那么简单交换机、对端网卡、协议栈都要配合才能把“并行链路”变成“逻辑大带宽”。我见过很多新人对 bond 抱有过高期望以为只要把两块网卡绑上所有问题就解决了。实际里你必须先搞清楚自己到底要解决什么问题是要避免“一块网卡挂了导致断网”这种故障还是需要“两条链路同时分担流量”这两类需求对应的配置完全不同。前者主要是冗余后者是负载均衡Bond 的模式就是在这两者之间做取舍。1.2 七种工作模式先分清哪些能用Linux 内核原生支持七种 Bond 模式我每次给新同事讲都直接用这张表表达比较直接模式正式名称是否需要交换机配合是否提升带宽容错使用建议mode 0balance-rr最好配合使用是是平时少用跨交换机风险大mode 1active-backup不需要否是最保守最常用mode 2balance-xor可配合静态聚合是是需要算好哈希mode 3broadcast不需要否是场景极少mode 4802.3ad必须配合 LACP是是生产环境首选mode 5balance-tlb不需要发送方向提升是适合不想动交换机的场景mode 6balance-alb不需要收发均提升是比 mode 5 更完整但兼容性要测试mode 4 是我们常说的 LACP 动态链路聚合要求交换机端口也开启 LACP两端协商成功后链路才真正“聚合”起来。mode 1 主备模式完全不挑交换机只要两块物理网卡能连到同一个二三层网络就行缺点是同一时间只有一块卡在工作浪费了另一块口的带宽但换来的是最少的配置和理解成本。像一些临时项目、没有网络设备权限的场景、或者只有普通傻瓜交换机的机房我基本都建议先上 mode 1。另外两个模式也提一下。mode 2 balance-xor 是根据 MAC 地址做异或运算选择出口如果只有两个口MAC 地址变化不大的时候很容易哈希到同一个口带宽调度效果不稳定现在用得比较少。mode 5 和 mode 6 不需要交换机配合而是通过修改发送端 ARP 或者改变源 MAC 的方式让交换机认为流量来自不同的主机从而实现负载均衡听起来很聪明但实际效果受交换机 MAC 学习机制影响很大不是所有设备都兼容。1.3 模式选错的典型反面案例我见过一个真实案例同事在一台双千兆服务器上配了 mode 0连的是一台不支持链路聚合的普通交换机。最开始压力小看不出问题后来业务高峰一上来流量稍微大一点就开始丢包应用端频繁报超时。当时又赶上交换机端口统计发现两块网卡所在口的 RX/TX 都不均衡查到最后才意识到是 mode 0 发包轮询到两条物理链路上而交换机对每个 MAC 地址的转发路径学习结果不一致回包经常从另一个口进来再加上协议栈收到的包顺序被打乱表现自然就是网络“卡死”。从那之后我给团队定了一条规矩没有充分的测试报告生产环境不允许用 mode 0 和 mode 6。不是说这两个模式绝对不能用而是它们对链路质量和交换机行为要求太高普通运维很难在每个场景下都验证到位。能用 mode 4 的尽量上 mode 4能不动脑筋的选 mode 1这是最可靠的组合。2. 配置前必须搞清楚的几个前提2.1 交换机与 Bond 模式的匹配关系Bond 配置从来不是服务器单方面的事。mode 4 要求交换机端口是动态 LACP 模式也就是常见配置里的“port-channel”或者“eth-trunk”而且两端协商速率、双工等参数要一致。如果交换机那边没配置或者配置成了静态 trunk服务器能做起来但实际上流量可能只走一个口甚至在极端情况下会广播环路。反过来有的交换机支持静态链路聚合不跑 LACP 协议那服务器端用 mode 2 可以配合但聚合成不成功要看交换机的哈希算法和服务器是否匹配。我建议的做法是先在交换机上确认支持哪种模式再决定服务器 bond 的 mode。不要先配好服务器再回头去求网络同事“帮忙打开聚合”这样容易两边各自为政出问题互相甩锅。这里还要注意“跨交换机”的问题。如果是两台交换机之间没有堆叠或者 MLAG 能力不建议把同一个 bond 的两个成员口分别接到这两台设备上尤其是 mode 4。因为 LACP 要求所有成员口必须在同一个聚合组里两台独立的交换机无法完成这种协商即使 mode 1 主备模式下跨设备也需要保证两台交换机二层互通而且故障切换后可能触发广播风暴风险很高。最稳妥的做法是把 bond 的两个成员口接到同一台交换机或者接到部署了堆叠的两台交换机上。2.2 网卡硬件和驱动的一致性检查另一个常被忽略的点是硬件一致性。Bond 的两块物理网卡最好是同型号、同速率、同一个驱动版本这样切换或负载均衡时才不会出现能力不匹配。比如一块千兆、一块万兆绑在一起mode 1 还能勉强做故障切换但一旦切到低速率网卡业务带宽会直接掉一个数量级mode 4 更是要求两端速率相同否则聚合成员协商会失败。检查命令很简单ethtool ens2f0 ethtool ens2f1看 Speed、Duplex、Driver 和 firmware 版本尽量保持一致。还要注意 PCIe 插槽带宽有的服务器网卡插在 x4 或 x1 槽上跑不满万兆Bond 之后会把问题放大。这种硬件层的问题很难从配置上解决所以配置前花五分钟检查能省掉后面一晚上的故障工单。如果条件允许给网卡固件做个升级也值得考虑。Intel 和 Mellanox 的网卡固件版本差异有时会影响 LACP 协商的兼容性和 driver 稳定性。不要小看这个细节物理网卡错误率偏高、链路反复 up/down很多时候都是固件和驱动版本太老导致的而不是 bond 配置本身写错。尤其是热搜里提到的 Mellanox 网卡 DPDK 测试场景固件不升级性能测试结果很容易被干扰。2.3 用 NetworkManager 还是传统 network 脚本RHEL/CentOS 7 开始系统默认用 NetworkManager 管理网络但很多老运维的习惯是直接写 /etc/sysconfig/network-scripts/ifcfg-* 文件。这两种方式如果混着用非常容易出现“配置明明写了但不生效”的情况因为 NetworkManager 可能把 network.service 的网络配置覆盖掉或者反过来 network.service 起来后把 NM 创建的连接干掉。我个人的建议是要么全程用传统的 ifcfg 加 network.service要么全程用 nmcli。CentOS 7.9 的环境里传统方式依然可靠前提是把 NetworkManager 的接管关干净如果你要用 nmcli就不要再手动去改 ifcfg 里的 IP 和 MASTER 字段否则两边状态不一致重启后大概率出问题。后面的实操部分我会把两种方式都写出来供你按团队习惯选择。另外CentOS 8/9 以及很多新系统已经彻底转向 NetworkManagerifcfg 文件虽然兼容但不再推荐。如果你用的是新系统直接用 nmcli 更符合趋势。还有 openEuler、Fedora Server 这些系统网卡配置文件的位置和字段也有差异配置前先看一下发行版文档不要盲目复制 CentOS 7 的做法。2.4 管理口、业务口与拓扑的风险点配置 Bond 前还要想清楚哪些口是管理口哪些口是业务口哪些口不能绑。最典型的反面教材是运维通过 SSH 登录服务器随手把服务器的 eth0 和 eth1 绑成 bond0结果 eth0 是唯一管理链路bond 配置过程中 network 服务一重启SSH 断了人又不在机房只能打电话求助远程控制卡或者现场工程师。这种事情我在工作里遇到过不止一次。所以我的习惯是如果 bonding 的对象里有管理口先确认有带外管理比如 IPMI/DRAC/iLO或者物理控制台可用再执行配置。另外不要跨交换机做 mode 4除非你那两台交换机支持 MLAG/堆叠并已经配置好否则 LACP 协商、回包路径都会有问题。跨设备做主备模式倒是可以考虑但需要连到不同的交换机上且网络二层是互通的前提是要对端交换机之间有正确配置。还有一个容易被忽略的点Bond 成员口不能同时被 IP 地址占用。如果你原来的 eth0 和 eth1 上各配了一个 IP把它们设成 bond 的 slave 后物理网卡上的 IP 必须清掉否则会出现路由冲突和 ARP 异常。配置前最好先把不需要的旧配置备份一下再动手修改。3. 一步步配置 Linux Bond 的完整记录3.1 准备工作和方案选择这里我以 CentOS 7.9 环境为例服务器是双口 Intel X710 万兆网卡两个口分别叫 ens2f0 和 ens2f1接在同一台交换机上交换机侧已经做好了 LACP 链路聚合组。目标是把这两个口聚合成 bond0配置一个业务 IP网关指向 192.168.10.1。这种场景我推荐 mode 4因为万兆口只做主备有点浪费既然交换机支持 LACP就用满带宽冗余。配置前先确认网卡信息ip link show ethtool ens2f0 ethtool ens2f1如果两个口名和我的示例不一样以你机器实际为准。还要确认 bonding 内核模块是否已经加载通常 CentOS 7 默认都有了但为了保险可以手动执行一次modprobe bonding lsmod | grep bonding如果提示模块不存在检查内核是否带了 bonding或者重新安装 kernel-modules-extra 包。这一步没有做后面配置完重启通常不会自动加载模块bond0 自然起不来。3.2 传统 ifcfg 方式配置 mode4先创建 bond0 的配置文件 /etc/sysconfig/network-scripts/ifcfg-bond0内容如下DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes ONBOOTyes BOOTPROTOstatic IPADDR192.168.10.10 NETMASK255.255.255.0 GATEWAY192.168.10.1 BONDING_OPTSmode4 miimon100 lacp_ratefast xmit_hash_policylayer34这里面有几点要说清楚。miimon100 表示每 100 毫秒检测一次链路状态这是 Bond 判断物理链路是否存活的重要机制。lacp_ratefast 表示 LACP 报文发送速率是快速模式如果交换机侧不是 fast就要改成 slow必须两端一致。xmit_hash_policylayer34 是 mode 4 下常用的负载均衡哈希策略根据源/目的 IP 和端口计算分发到哪个成员口能有效减少小连接场景下的哈希不均问题。然后修改两块物理网卡的配置文件。如果原来这两个文件有 IP 设置全部清掉只保留成员角色。以 ens2f0 为例DEVICEens2f0 NAMEens2f0 TYPEEthernet ONBOOTyes BOOTPROTOnone MASTERbond0 SLAVEyesens2f1 的内容一样把 DEVICE 和 NAME 改成 ens2f1。这里有个细节如果服务器存在可预测网卡命名规则建议在文件中写上 HWADDR把 MAC 地址固定住防止换 PCIe 插槽后系统把接口名改了bond 成员找不到。配置完先加载 bonding 模块再重启网络modprobe bonding systemctl restart network如果想要开机自动加载 bonding 模块在 /etc/modprobe.d/bonding.conf 文件里加一行options bonding miimon100 mode4 lacp_ratefast xmit_hash_policylayer34注意这样一来ifcfg-bond0 里可以不用重复写 BONDING_OPTS两种方式都是内核参数加载的一种途径但不要一个参数写两遍又不一样会让人很难排查。我一般习惯把参数写在 ifcfg 里模块本身不加载参数这样网络配置集中在一个文件看的时候更直观。也有人喜欢写在 modprobe.d 里团队统一即可。3.3 nmcli 方式配置 mode1 或 mode4如果你习惯用 NetworkManager 管理网络或者团队要求所有配置都走 nmcli那么可以完全不碰 ifcfg 的 MASTER 字段。比如要配一个 mode 1 的主备 bond首先创建 bond 连接nmcli con add type bond ifname bond0 con-name bond0 mode active-backup nmcli con modify bond0 ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.method manual nmcli con add type ethernet ifname ens2f0 con-name ens2f0 master bond0 nmcli con add type ethernet ifname ens2f1 con-name ens2f1 master bond0 nmcli con up bond0这里 mode 参数可以直接用模式名字active-backup、balance-rr、balance-xor、broadcast、802.3ad、balance-tlb、balance-alb。如果想配 mode 4把 mode 参数换成 802.3ad 即可。之后查看状态nmcli connection show bond0 nmcli device statusnmcli 的优势是配置写入到 NetworkManager 自己的配置目录不容易和 network.service 冲突缺点是很多习惯了 ifcfg 的老运维会找不到文件位置。其实 NetworkManager 生成的配置文件也能直接看通常在 /etc/sysconfig/network-scripts/ 下只不过多了一些 UUID、connection.id 之类字段逻辑是一样的。还要注意如果想把 bond 设置成开机自启用 nmcli 时执行nmcli con mod bond0 connection.autoconnect yes不然可能重启后 bond 连接存在但没有自动拉起这个点经常有人踩。3.4 配置后的验证与拔线测试无论在哪种方式下配置完成后都要验证 Bond 是否真正工作。先看逻辑接口信息ip addr show bond0 cat /proc/net/bonding/bond0/proc/net/bonding/bond0 的输出非常关键mode 4 正常情况下会显示Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer34 MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: fast Aggregator selection policy (ad_select): stable Slave Interface: ens2f0 MII Status: up Speed: 10000 Mbps如果两个 slave 都是 upSpeed 都是 10000说明物理链路和 LACP 协商都正常。接下来做一次拔线测试在业务低峰期把其中一根网线拔掉观察丢包情况。mode 1 的切换动作通常在 1 秒内完成mode 4 会有重新协商但正常配置下业务中断时间也很短。拔线时注意看 /var/log/messages 里 bond 相关的链路 down/up 事件确认它对中间过程有感知。如果条件允许还可以用 iperf3 打流测试实际带宽比如一端接在 bond0 上另一端接在同样能力的链路上跑满后用 ethtool -S 查看两个成员口有没有都有流量以此判断负载均衡是否生效。不要只看 ip addr 显示 up 就觉得万事大吉实际压力测试才是检验聚合效果的唯一标准。4. 常见故障与排查经验4.1 绑不上或重启失效我遇到最多的报错是“bond0 创建成功但没有流量”或者“重启后配置全部丢失”。这类问题八成出在配置文件与系统网络管理方式冲突上。排查时按这个顺序来确认 /etc/sysconfig/network-scripts/ifcfg-bond0 存在且内容正确运行systemctl status network看 network.service 是否正常启动运行nmcli device status看有没有接口被 NetworkManager 接管确认 /etc/modprobe.d/bonding.conf 里是否做了重复或冲突的参数设置查看/var/log/messages里有没有 bonding 模块加载失败的记录。如果是传统 ifcfg 方案建议直接把 NetworkManager 服务停掉或者把网卡配置里加NM_CONTROLLEDno避免两边抢接口。很多 CentOS 7 环境重启后出现“bond 起来了但成员口没加入”就是 NetworkManager 在 network.service 之后又把网卡拉走导致的。另外如果网卡命名是 ens2f0 这种但是 ifcfg 文件里 DEVICE 写错了名称systemd 会找不到对应的物理接口。最好在配置前用ip link确认接口名不要凭记忆写。还有一种情况是 ifcfg 文件的权限或属主不对导致 network.service 拒绝读取虽然少见但也会让配置像消失了一样。4.2 绑了之后反而更慢如果配置完发现网络变慢第一时间不要怀疑“多卡并联怎么会慢”很可能是负载均衡策略和交换机不匹配。我看过一个 case业务是一堆长连接xmit_hash_policy 用的是默认的 layer2结果所有回包都哈希到同一个物理口上另一块卡闲着还因为乱序导致应用层不稳定。后来把哈希策略改成 layer34情况立刻改善。另外mode 5 和 mode 6 这种自适应模式在某些交换机上并不支持源 MAC/ARP 协商机制可能出现“一个口狂收包、另一个口完全空闲”的情况。真遇到这种非线性问题就老老实实改回 mode 4 或 mode 1别在一个选项上死磕。还有一点bond 成员口的速率协商不一致时也会出现瓶颈。比如一块网卡协商成千兆另一块却协商成百兆流量如果哈希到百兆口业务就会突然变慢。这种时候 ethtool 看到两个口 speed 不同优先检查网线、光模块和交换机端口配置而不是急着改 bond 参数。4.3 虚拟化环境里特别容易踩的坑在 VMware ESXi 或 Hyper-V 宿主机里Linux 虚拟机内部做 Bond 需要尤其谨慎。虚拟机的两块虚拟网卡可能映射到宿主机同一块物理网卡也可能走同一个虚拟交换机你以为做了物理冗余实际上虚拟化层一断两个口一起断根本起不到故障切换作用。真正要链路冗余和带宽聚合应该在虚拟化宿主机层面做把多块物理网卡聚合成 vSwitch 的上行链路再让虚拟机虚拟网卡连接到这个 vSwitch 上而不是在虚拟机系统里绑两个虚拟网卡。PVE 也是一样PVE 的 GUI 里可以直接创建 Linux bond然后再建 bridge 把虚拟机接上去。虚拟机里显示的双网卡可能只是同一个 bridge 的两个虚拟接口没有物理层面的意义。所以排查虚拟化网络问题时先看宿主机物理网卡、bond/bridge 和 vSwitch 的配置再回来看虚拟机内部的网络配置。如果你确实需要在虚拟机内部测试 bond 配置我建议只在测试环境做并且明确给虚拟网卡分别连接到不同的虚拟交换机上这样至少能模拟一下“上行链路不同”的情况。但大多数实验环境没这个条件所以不要把虚拟机内 bond 当成生产高可用方案。像 vSphere 里报“检查物理网卡错误率较高”这种情况往往也不是虚拟机内 bond 能解决的而是宿主机物理网卡、驱动、光模块的问题。4.4 命名、自启与一致性问题的其他坑CentOS 7 开始接口命名普遍是 ens2f0 这种形式它跟 PCIe 插槽位置有关。如果你把网卡从某个插槽换到另一个插槽接口名可能变成 ens3f0原来写死的 SLAVEyes 就找不到网卡了。解决思路有两个一个是在 ifcfg 里写 HWADDR 固定 MAC二是尽量不要频繁更换物理插槽。服务器交付时做好网卡、MAC、接口名的台账能省掉很多问题。“开机自启”也是高频问题。不管是 ifcfg-bond0 还是成员口都要确保 ONBOOTyes同时 bond0 要比成员口先起来这些在传统配置里通常没问题。如果你是用 nmcli 创建的连接记得最后执行nmcli con mod bond0 connection.autoconnect yes不然重启后 bond0 不会自动拉起来。还有一个容易忽略的坑如果服务器上有两个 bond 配置比如 bond0 和 bond1它们的成员口不能交叉使用。也就是说同一块物理网卡只能属于一个 bond不能既给 bond0 又给 bond1。有些人为了省网口把接口配置改来改去最后出现奇怪的 MAC 和链路状态排查起来非常痛苦。建议规划网络时给每个物理网卡明确角色不要复用。4.5 怀疑交换机侧聚合异常时的自测手段想快速判断交换机侧是否真的和自己的 Bond 协商成功可以在服务器上敲cat /proc/net/bonding/bond0看 Slave Interface 对应的 MII Status以及 802.3ad info 里有没有 Learning、Distributing 等状态。如果成员口虽然 up 但没有进入聚合组通常是因为交换机端 LACP 没有配置或者两端的 lacp_rate、模式不匹配。这时联系网络同事核对交换机端口聚合状态一般都能定位。也可以用 tcpdump 在 bond0 上抓包看是否所有流量都在逻辑接口上正常进出再分别抓成员口确认数据包确实分布在多条物理链路上。这些手段组合起来能覆盖九成以上的 bond 排查场景。另外日志里如果反复出现 “link failure” 或 “link down” 记录说明物理链路真的在闪断。这时候不要只盯着 bond 参数先检查光纤收发功率、网线接头、交换机端口 error counter。很多所谓的“bond 不稳定”问题真相是光模块不兼容或者两端的协商参数不对。5. 场景化选型和我的建议5.1 选型速查场景推荐模式理由交换机支持 LACP业务需要吞吐mode 4带宽叠加和容错兼顾只有普通交换机或不想协调网络mode 1纯主备不挑设备两块网卡速率不同只要冗余mode 1避免聚合模式因速率不匹配失败直连两台服务器不想用交换机mode 5/6 或 mode 1需要实测注意兼容性虚拟化宿主机mode 4 或 mode 1配合 vSwitch关键是宿主机层聚合不是虚拟机内对延迟敏感的小包业务mode 4 layer34尽量保证哈希均匀减少乱序这并不是硬性规定但能作为大多数场景的起点。实际生产环境里我见过很多从 mode 0 改成 mode 1 后问题立刻消失的案例也见过 mode 4 万兆分布式存储跑得特别顺的案例选型的关键是匹配你的网络设备和业务特征。还有一个容易被忽略的问题Bond 和 VLAN 的组合。如果你的服务器上要跑多个 VLAN可以把 VLAN 建在 bond0 之上而不是在物理网卡上分别建 VLAN。做法是创建 bond0.10、bond0.20 这样的子接口这样多个业务网段共享同一组物理链路又能在逻辑上隔离。需要注意的是如果交换机对应端口是 trunk 口必须放通对应 VLAN否则子接口虽然能起来但网络不通。5.2 两条保命经验第一条永远不要把 Bond 配置完成作为项目的终点。你还需要把“交换机端口成员关系、服务器 bonding 参数、网卡型号和固件版本、物理链路编号”全部记录到文档里否则过半年之后没人能说清当时的聚合是怎么设计的。第二条上线前一定要做故障演练。拔一根线、拔两根线、重启交换机端口、换光模块各种链路异常都模拟一遍。Bond 能在绝大多数场景下自动恢复但它不是魔法如果成员口对应的交换机端口被配置成了 access 口或 VLAN 不对拔线演练时就会立刻暴露问题而不是等到业务高峰再翻车。最后再分享一个习惯我在每次配完 bond 之后都会顺手在 /var/log/messages 里 grep 一遍 “bonding” 关键字确认没有反复的 link down/up 记录再保存一份cat /proc/net/bonding/bond0的快照到运维文档。等哪天真出问题这个快照能帮你快速判断是“配置没起来”还是“链路一直不稳定”。Bonding 是基础技术但越基础的东西越值得多花点时间做透这是我被现实教育过很多次之后才养成的习惯。