企业官网建设流程全解析

干运维这些年，半夜被电话叫起来处理网络故障，十次里得有七八次和网卡绑定有关。刚入行的时候，我总以为 bond 就是把几块网卡捆在一起提升速度，直到有一次在业务高峰期把核心数据库的网络绑得近乎瘫痪，才老老实实把 Linux bonding 的原理和每种模式的脾气摸了一遍。这篇小记算是我个人的实践笔记，写给要处理物理机双网卡 bonding 的运维同行，也写给刚接触 Linux 网络基础的朋友。

Bond 这个功能，在 Linux 内核里已经存在二十多年了，简单说就是把多块物理网卡聚合成一块逻辑网卡，对外暴露同一个 IP，对内按算法把数据流分到不同的物理链路。听着不复杂，但具体用哪种模式、交换机端怎么配合、虚拟化环境怎么处理，里面坑特别多。我先把适用范围说清楚：如果你是在物理服务器上做链路冗余，或者刚接触 Linux 网络配置，又或者总在虚拟机环境里被网卡问题绕晕，这篇内容应该能给你省点弯路；如果你对 bond 已经很熟，可以直接跳到第 3 节看配置，或者到第 4 节看踩坑记录。

1. 先弄明白 Bond 这件事的本质

1.1 它解决的是单点故障，不只是带宽

很多朋友听说 Bond 第一反应是“带宽翻倍”，这个理解其实只对了一半。Bond 最早解决的是链路单点故障问题：一块物理网卡、一根网线、交换机一个端口，任何一个环节出问题，业务就断了。服务器如果跑的是数据库、存储节点、虚拟化宿主机，断一次网带来的可能就是长时间业务中断，甚至集群脑裂。把两块网卡做成主备关系后，物理链路挂了可以在秒级自动切到另一条，这才是 Bond 最核心的价值。

至于带宽叠加，要看具体模式。最简单粗暴的 balance-rr（mode 0）会把数据包轮流从多块网卡发出去，理论上两块千兆卡能跑满 2Gbps，但实际上对端交换机如果没有做相应的链路聚合，数据包可能走不同的物理路径到达，接收侧重排数据包的负担会很大，表现就是速度不但没提升，反而丢包、乱序。网络传输不是两根水管直接并在一起那么简单，交换机、对端网卡、协议栈都要配合才能把“并行链路”变成“逻辑大带宽”。

我见过很多新人对 bond 抱有过高期望，以为只要把两块网卡绑上，所有问题就解决了。实际里，你必须先搞清楚自己到底要解决什么问题：是要避免“一块网卡挂了导致断网”这种故障，还是需要“两条链路同时分担流量”，这两类需求对应的配置完全不同。前者主要是冗余，后者是负载均衡，Bond 的模式就是在这两者之间做取舍。

1.2 七种工作模式，先分清哪些能用

Linux 内核原生支持七种 Bond 模式，我每次给新同事讲都直接用这张表，表达比较直接：

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 以及很多新系统已经彻底转向 NetworkManager，ifcfg 文件虽然兼容，但不再推荐。如果你用的是新系统，直接用 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 方式配置 mode=4

先创建 bond0 的配置文件 /etc/sysconfig/network-scripts/ifcfg-bond0，内容如下：

DEVICE=bond0 NAME=bond0 TYPE=Bond BONDING_MASTER=yes ONBOOT=yes BOOTPROTO=static IPADDR=192.168.10.10 NETMASK=255.255.255.0 GATEWAY=192.168.10.1 BONDING_OPTS="mode=4 miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"

这里面有几点要说清楚。miimon=100 表示每 100 毫秒检测一次链路状态，这是 Bond 判断物理链路是否存活的重要机制。lacp_rate=fast 表示 LACP 报文发送速率是快速模式，如果交换机侧不是 fast，就要改成 slow，必须两端一致。xmit_hash_policy=layer3+4 是 mode 4 下常用的负载均衡哈希策略，根据源/目的 IP 和端口计算分发到哪个成员口，能有效减少小连接场景下的哈希不均问题。

然后修改两块物理网卡的配置文件。如果原来这两个文件有 IP 设置，全部清掉，只保留成员角色。以 ens2f0 为例：

DEVICE=ens2f0 NAME=ens2f0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=none MASTER=bond0 SLAVE=yes

ens2f1 的内容一样，把 DEVICE 和 NAME 改成 ens2f1。这里有个细节：如果服务器存在可预测网卡命名规则，建议在文件中写上 HWADDR，把 MAC 地址固定住，防止换 PCIe 插槽后系统把接口名改了，bond 成员找不到。

配置完，先加载 bonding 模块，再重启网络：

modprobe bonding systemctl restart network

如果想要开机自动加载 bonding 模块，在 /etc/modprobe.d/bonding.conf 文件里加一行：

options bonding miimon=100 mode=4 lacp_rate=fast xmit_hash_policy=layer3+4

注意，这样一来，ifcfg-bond0 里可以不用重复写 BONDING_OPTS，两种方式都是内核参数加载的一种途径，但不要一个参数写两遍又不一样，会让人很难排查。我一般习惯把参数写在 ifcfg 里，模块本身不加载参数，这样网络配置集中在一个文件，看的时候更直观。也有人喜欢写在 modprobe.d 里，团队统一即可。

3.3 nmcli 方式配置 mode=1 或 mode=4

如果你习惯用 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 status

nmcli 的优势是配置写入到 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: layer3+4 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 都是 up，Speed 都是 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_CONTROLLED=no，避免两边抢接口。很多 CentOS 7 环境重启后出现“bond 起来了但成员口没加入”，就是 NetworkManager 在 network.service 之后又把网卡拉走导致的。

另外，如果网卡命名是 ens2f0 这种，但是 ifcfg 文件里 DEVICE 写错了名称，systemd 会找不到对应的物理接口。最好在配置前用ip link确认接口名，不要凭记忆写。还有一种情况是 ifcfg 文件的权限或属主不对，导致 network.service 拒绝读取，虽然少见但也会让配置像消失了一样。

4.2 绑了之后反而更慢

如果配置完发现网络变慢，第一时间不要怀疑“多卡并联怎么会慢”，很可能是负载均衡策略和交换机不匹配。我看过一个 case：业务是一堆长连接，xmit_hash_policy 用的是默认的 layer2，结果所有回包都哈希到同一个物理口上，另一块卡闲着，还因为乱序导致应用层不稳定。后来把哈希策略改成 layer3+4，情况立刻改善。

另外，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，原来写死的 SLAVE=yes 就找不到网卡了。解决思路有两个：一个是在 ifcfg 里写 HWADDR 固定 MAC，二是尽量不要频繁更换物理插槽。服务器交付时做好网卡、MAC、接口名的台账，能省掉很多问题。

“开机自启”也是高频问题。不管是 ifcfg-bond0 还是成员口，都要确保 ONBOOT=yes，同时 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 选型速查

这并不是硬性规定，但能作为大多数场景的起点。实际生产环境里，我见过很多从 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 是基础技术，但越基础的东西越值得多花点时间做透，这是我被现实教育过很多次之后才养成的习惯。