OpenStack Neutron Linuxbridge vs OVS：踩坑选型笔记
新搭 OpenStack 集群时一定会问的问题：Neutron 后端选 Linuxbridge 还是 OVS？本文是我在生产 + 测试两套集群跑了两年后的结论。
一句话答案
- 没特殊需求 → Linuxbridge：简单、稳、排查容易
- 要 SDN / DPDK / 复杂网络策略 → OVS：功能强、性能更好、但学习曲线陡
- 要分布式 router / SR-IOV / vxlan offload → OVS（或者更激进的 OVN）
对比维度
| 维度 | Linuxbridge | OVS |
|---|---|---|
| 配置复杂度 | 简单 | 中-高 |
| 性能（包量） | 中 | 高（DPDK 模式更高） |
| 功能丰富度 | 基础（vlan/vxlan/flat） | 强（flow、qos、meter、bond） |
| 故障排查 | brctl + tcpdump，思路简单 |
ovs-vsctl + ovs-ofctl dump-flows，需懂 OpenFlow |
| 社区方向 | 稳定但不再发力 | 主流，OVN 是未来 |
Linuxbridge 的优点（容易被低估）
- 就是 Linux 桥：所有 Linux 网络工具直接能用，没有抽象层
- 没有 OpenFlow flow 表：一个 vlan 一个 bridge，看一眼就懂
tcpdump直接抓包：哪个 tap 卡了立刻定位- 重启 agent 不会断流：因为内核态的 bridge 不依赖用户态进程
我们一个生产集群跑 Linuxbridge 三年，零网络故障。
OVS 的痛点（也容易被低估）
- flow 表难读：
ovs-ofctl dump-flows br-int出来几百条，肉眼看是看不懂的 - ovs-vswitchd 挂了断网：进程死了所有 VM 网络断（Linuxbridge 不会）
- 重启 ovs-vswitchd 抖动：百毫秒级丢包，搞过的都懂
- 加 flow 不刷新可能有缓存：诡异问题
但优点真的很顶：
- vxlan offload：网卡支持的话性能直接翻倍
- DVR（分布式 router）：南北向流量不再走 network node
- 细粒度 QoS / 流量镜像 / ACL：Linuxbridge 干不了
一个非常坑的事
如果你选 OVS，强烈建议直接上 OVN，别用 ML2/OVS。原因：
- ML2/OVS 是 Neutron agent 算 flow 推到 OVS，agent 挂了网络新建就停
- OVN 是控制面（ovn-northd）下发到节点的 ovn-controller，去掉了 Neutron agent
- OVN 的 logical switch / router 模型比 ML2 干净
但 OVN 切换成本不低，老集群在线切几乎不可能，规划期就要选好。
我的选型建议
| 场景 | 选 |
|---|---|
| 小规模（<50 节点）私有云、传统业务 | Linuxbridge |
| 公有云、需要租户隔离 + 高吞吐 | OVS / OVN |
| 边缘集群、单节点 all-in-one | Linuxbridge |
| 要做 SDN、Service Mesh 对接 | OVN |
切换的代价
我们做过 Linuxbridge → OVS 的迁移：
- 涉及节点：35 台 compute
- 准备时间：1 个月（包括功能测试、性能压测、回滚方案）
- 执行时间：3 个晚上的维护窗口
- 业务影响：每台节点的 VM 需要 live-migrate 走再切，单台约 30 分钟
不是不能切，是确实折腾。
教训一句话：网络后端是 OpenStack 最难切的东西，搭集群前花一天评估，比上线后花一个月迁移划算。