PVE 踩坑笔记：网桥 vmbr0 偶发断流，宿主机本身网络正常，VM/LXC 随机掉线

一、故障表现

• 宿主机物理网卡连通稳定，宿主机 ping 网关、外网持续正常，无丢包
• 桥接在 vmbr0 上的 VM、LXC 随机断流，断流期间 ping 网关超时
• 断流持续一段时间后自动恢复，不需要重启网桥或者虚拟机
• 流量高、广播包多的时候，断流概率明显升高
• 交换机上没有端口 down、没有 CRC 报错，网卡ethtool -S看不到持续增长的 error
• 重建网桥、重启节点短暂好转，一段时间后故障复现

典型特征：宿主机物理网卡正常，只有网桥转发的虚拟机流量被阻断，属于 Linux 网桥特有疑难问题。

二、原理简单说明

PVE 里的 vmbr 本质是 Linux kernel bridge。宿主机自身流量是直接走物理网卡，不经过网桥转发；而 VM/LXC 的流量由网桥内核模块转发。 所以会出现：宿主机网络正常，虚拟机流量单独异常。 常见触发逻辑：广播风暴触发网桥内核风暴保护、物理网卡开启 bridge offload 和内核网桥冲突、STP 环路冲突、ebtables/iptables 二层规则拦截、网卡 TX/RX 队列溢出。

三、排查顺序

1. 先确认网桥、物理网卡状态

# 查看网桥信息
brctl show vmbr0
bridge link show vmbr0

查看所有绑定到网桥的端口（物理网卡 + 各 VM 虚拟网卡 tap 设备）

1. 查看网桥风暴抑制参数

sysctl net.bridge.bridge-nf-call-iptables
sysctl net.bridge.bridge-nf-call-arptables

1. 查看网桥日志，重点抓断流瞬间

journalctl -k -f | grep -E "bridge|br_|tap"

内核日志出现 broadcast storm 基本锁定风暴抑制触发。

1. 查看网卡 offload 卸载特性

ethtool -k enp0s31f6

重点关注 bridge forwarding offload

1. 断流时刻，在宿主机抓包对比

# 抓网桥流量
tcpdump -i vmbr0 host 虚拟机IP
# 抓物理网卡流量
tcpdump -i enp0s31f6 host 虚拟机IP

对比：物理网卡收到包，但是网桥没有转发给 tap 设备，就是内核网桥拦截。

四、分场景修复方案

场景 1：广播风暴触发内核网桥风暴抑制（最高频）

Linux 网桥默认有广播风暴保护，当网桥内短时间大量广播 / 组播包，内核会临时抑制转发，防止把整个网络打挂，表现就是虚拟机突然断流，等待阈值恢复后自动通。

常见诱因：虚拟机内 ARP 风暴、Windows 机器网络探测、环路、设备大量 DHCP 请求。

查看风暴控制（部分版本通过 sysctl，部分通过 bridge 命令）：

bridge link show

如果配置了 broadcast_flood 0 或者风暴阈值很低，就容易误触发。

临时测试关闭风暴抑制验证：

bridge link set dev enp0s31f6 broadcast_flood on

生产环境不建议直接关闭风暴抑制，正确做法：

1. 找到产生广播风暴的虚拟机，定位异常主机；
2. 在交换机侧配置广播风暴抑制，粒度比 Linux 网桥更合适；
3. 虚拟机内部排查 ARP 扫描、病毒、环路。

场景 2：bridge forwarding offload 网卡卸载冲突

部分万兆网卡支持 bridge forwarding offload，把网桥转发卸载到网卡硬件。 这个特性和 PVE 网桥、tap 设备兼容性很差，容易出现随机转发失效。 关闭该 offload 测试：

ethtool -K enp0s31f6 bridge off

关闭后持续观察是否还会断流。很多 Intel、Mellanox 网卡遇到过这个坑。

场景 3：bridge-nf 开启，二层流量被 iptables/ebtables 拦截

bridge-nf-call-iptables=1 会让网桥二层流量经过 iptables 过滤。 如果 PVE 防火墙规则、ebtables 规则存在隐式丢弃，会随机丢包断流。 容器、虚拟机流量会被二次过滤，宿主机本机流量不受影响。

# 查看参数
sysctl net.bridge.bridge-nf-call-iptables

PVE 环境如果使用 PVE 防火墙，这个参数配合不当极易出问题。

测试方案：临时设置为 0 验证

sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-arptables=0

⚠️ 注意：关闭后 PVE 防火墙二层规则失效，生产环境要权衡安全。

场景 4：STP 生成树冲突，交换机 STP 和网桥 STP 同时开启

vmbr 默认 STP 关闭，但是如果手动开启了网桥 STP，同时上游交换机也开启 STP，BPDU 报文冲突，网桥端口会被置为 blocking，虚拟机断流。

检查网桥 STP 状态：

brctl showstp vmbr0

PVE 的 vmbr绝大多数场景不需要开启 STP，STP 交给物理交换机处理。

brctl stp vmbr0 off

场景 5：tap 虚拟网卡队列溢出，虚拟机流量丢包

大量虚拟机并发流量，tap 设备 rx 队列溢出，内核丢弃报文。 查看 tap 丢包：

ethtool -S tap100i0

rx_dropped 持续上涨就是队列不足。 调整 tap 缓冲区，或者调整宿主机网卡 tx/rx 缓冲区。

场景 6：PVE 防火墙规则存在状态跟踪超时

PVE 节点防火墙，连接跟踪超时时间设置过小，长连接（SSH、数据库连接）会被防火墙规则断开，看起来像网桥断流。 区分方式：宿主机本身不受防火墙规则限制，虚拟机流量受管控。 临时关闭节点防火墙测试，用来定位。

五、验证修复

调整完成后持续观察：

watch -n1 bridge link show

同时长 ping 虚拟机，持续压测流量，不再出现随机丢包断流即为修复。

六、高频踩坑点

1. 宿主机网络正常就直接排除物理网卡、链路问题，忽略 “宿主机流量不走网桥” 这个关键点；
2. 分不清交换机 STP 和 Linux 网桥 STP，两边同时开启 STP 造成端口阻塞；
3. 网卡默认开启 bridge forwarding offload，不知道这个特性和 PVE 网桥兼容性差；
4. 开启 bridge-nf-call-iptables 之后，二层流量被 iptables 干扰，只知道 PVE 防火墙却不知道 bridge-nf；
5. 把风暴抑制当成故障直接关掉，不溯源广播风暴源头，埋下更大网络风险。