避坑指南：Linux NetworkManager 配置 Bond 网卡绑定与 Bridge 桥接实操

最近在折腾服务器网络的时候，遇到一个挺典型的“虽然报错但不知道为什么”的问题。很多兄弟在用 NetworkManager（后面简称 NM）做多网卡绑定时，想把 Bond0 再作为一个口子去桥接到 Bridge 上，结果发现要么起不来，要么网络不通。

今天咱们就把这个问题的来龙去脉理一理，毕竟在现在的 2026 年，虽然容器化和虚拟化已经非常成熟，但底层的网络 bonding + bridge 依然是高可用物理机的标配。

问题背景：想做的架构是什么样的？

通常我们想做这种架构，目的是为了在虚拟机（如 KVM、QEMU）或者容器底层提供一个高可用的二层网络出口。

直观的逻辑是这样的：

1. 物理层：有两块物理网卡，比如 eth0 和 eth1。
2. 绑定层：为了冗余和带宽，把它们绑成一个 bond0（模式一般是 4 或者 6，也就是 LACP 或自适应负载均衡）。
3. 桥接层：创建一个 br0，把 bond0 挂在 br0 下面，让虚拟机直接挂 br0，就像直接连在物理交换机上一样。

这个逻辑没毛病，问题通常出在 NM 的“连接”配置上。

核心痛点：“Master”与“Slave”的归属权争夺

NM 的核心管理单位是“Connection”。在这个场景下，最容易翻车的就是谁是谁的 Slave 搞混了。

错误示范

有些朋友会这样操作：

1. 创建一个 Bridge 连接 br0。
2. 创建一个 Bond 连接 bond0，并设置它的“连接从属”为 br0。
3. 把物理网卡的连接从属设置为 bond0。

看似逻辑通顺：物理 -> bond -> bridge。

但 NM 在某些版本或特定配置下，对于“既作为 Master 又作为 Slave”的接口处理会有冲突。 如果你在 bond0 上配置了 IP 地址，同时又把它设为 br0 的端口，NM 可能会因为 bond0 的控制器状态异常而罢工，或者导致 br0 无法正确获取 IP（因为 IP 冲突了）。

正确的配置姿势

其实，标准的做法是把重点分清楚：Bond 负责聚合，Bridge 负责交换。

推荐步骤如下：

1. 清理环境：先把涉及的物理网卡（ens33, ens34 等）相关的连接都删掉或停掉，确保它们处于“未托管”或空闲状态。

   nmcli con show
   nmcli con delete <旧连接名>
   

2. 创建 Bond 接口（纯二层聚合，不配 IP）： 这里创建 bond 时，不要给它设置 IP 地址（ipv4.method disabled），也不要急着把它挂给 bridge。

   nmcli con add type bond con-name bond0 ifname bond0 mode balance-rr
   # 也可以根据需求改 mode，比如 802.3ad
   

3. 将物理网卡挂入 Bond： 把物理网卡设为 bond0 的 slave。

   nmcli con add type ethernet slave-type bond con-name bond0-port-eth0 ifname eth0 master bond0
   nmcli con add type ethernet slave-type bond con-name bond0-port-eth1 ifname eth1 master bond0
   

4. 创建 Bridge 并接管 Bond： 创建 br0，把 IP 配在 br0 上，然后把 bond0 设为 br0 的slave。

   # 创建 bridge
   nmcli con add type bridge con-name br0 ifname br0 ip4 192.168.1.100/24 gw4 192.168.1.1
   
   

将 bond0 挂载到 br0

nmcli con add type ethernet slave-type bridge con-name br0-port-bond0 ifname bond0 master br0
```
*注意：这一步是关键。虽然 bond0 本身是 bond 类型的 master，但在 bridge 面前，它扮演的是 bridge 的一个端口角色。通过 NM CLI 创建一个 type 为 ethernet（或者 bond）但 slave-type 为 bridge 的连接，可以把这个逻辑理顺。*

常见报错与排查方法

就算配置对了，有时候也会遇到奇奇怪怪的问题，这里列几个 2026 年依然常见的坑：

1. Connection 'bond0' is not available

原因：通常是因为 bond 下的物理网卡没有 up 起来，或者 NM 没检测到物理链路。 解决：检查网线，或者用 nmcli dev status 看看物理网卡是不是 connected 状态。如果是虚拟机，检查虚拟交换机配置。

2. Bridge 无法获取 IP 地址

原因：可能是 STP（生成树协议）在搞鬼，导致端口处于 Blocking 状态太久。 解决：如果你确定没有环路风险，可以在 Bridge 连接里关掉 STP。 bash nmcli con modify br0 bridge.stp no nmcli con up br0

3. 虚拟机网络不通，宿主机能通

原因：防火墙规则或 ip_forward 转发问题。现在很多发行版默认用 nftables 或者 firewalld。 解决：检查 /etc/sysctl.conf 里的 net.ipv4.ip_forward=1 是否生效。如果是给虚拟机用，Bridge 基本上不需要复杂的防火墙规则，确保流量没有被 filter 表拦住即可。

优化建议

如果这台服务器是对外提供服务的，建议在 Bond 上配合“miimon”（链路监控）参数，这样一旦某根网线松了，Bond 能瞬间切换，而不是等到超时。

nmcli con modify bond0 bond.miimon 100
nmcli con modify bond0 bond.downdelay 200
nmcli con modify bond0 bond.updelay 200
``ncli con up bond0

总结

NetworkManager 虽然把Linux网络配置简化了很多，但在处理“套娃”式的网络拓扑时，依然需要分清 Master/Slave 的层级关系。牢记：IP 只配置在最外层的设备（在这个例子里是 br0），中间层专注于转发，不要让它们抢着当“老大”，基本就能避免绝大多数坑。

希望这篇笔记能帮到正在被 NetworkManager 折磨的你，如果有其他更奇怪的报错，欢迎在评论区交流！