OVS 仅提供 VTEP 能力，大二层由 VXLAN 接口、统一 VNI 和互通的三层 Underlay 网络共同实现；需确保内核加载 vxlan 模块且 OVS 支持隧道功能。
直接上结论：OVS 本身不“配置大二层网络”，它只提供 VTEP（VXLAN Tunnel End Point）能力；真正构成跨宿主机大二层的是 vxlan 接口 + 统一的 vni + 互通的三层 Underlay 网络。只要两台宿主机能 UDP 通信、ovs-vsctl add-port 命令正确绑定 remote_ip 和 vni，二层帧就能透传。
确认内核和 OVS 版本是否支持 VXLAN
很多连不通的问题，根源是内核没开 VXLAN 模块或 OVS 编译时没启用隧道支持。
-
modprobe vxlan && lsmod | grep vxlan必须有输出；若报错，说明内核未加载或版本太低（ -
ovs-vsctl --version查看输出中是否含tunnel或VXLAN字样；2.5+ 一般默认支持，但源码编译时若漏掉--with-linux=/lib/modules/$(uname -r)/build，可能缺失隧道驱动 - CentOS 7 默认内核 3.10，需确认
/lib/modules/$(uname -r)/kernel/net/vxlan/下存在vxlan.ko
用 ovs-vsctl 添加 VXLAN port 的关键参数
命令看着简单，但 options:remote_ip、options:key、options:dst_port 这三项错一个就 ping 不通。
-
remote_ip必须填对端宿主机的 Underlay IP（即物理网卡 IP），不能是 localhost、127.0.0.1 或容器网桥 IP -
key就是 VNI，必须两端一致；建议显式写成十六进制（如options:key=0x12345）或十进制（options:key=74565），避免被误解析为 “flow-based” 动态模式 -
dst_port默认是 8472，但若两端不一致（比如一端改过），会静默丢包；建议显式指定：options:dst_port=8472 - 不要依赖 auto-discovery：VXLAN 在 OVS 中是静态点对点隧道，不支持 multicast group 自动发现，
options:remote_ip必须写死
br0 上的流量路径必须清晰
OVS 网桥不是“自动转发一切”，br0 是否真把容器/VM 流量引向 vxlan port，取决于端口是否接入、IP 是否冲突、流表是否拦截。
- 确保 VM/container 的虚拟网卡（如
vethxxx或tap0）已用ovs-vsctl add-port br0 <iface>加入 br0，且该接口已ip link set up - br0 本身不要配 IP —— 若配了（如
ifconfig br0 172.17.0.2/24），它会抢走本该由容器/VM 处理的 ARP 和 ICMP，导致跨节点 ping 通但 TCP 不通 - 检查流表：
ovs-ofctl dump-flows br0应看到类似priority=0,actions=NORMAL的默认流；若被其他高优先级流（如 drop 或 goto-table）覆盖，二层泛洪会失效 - 物理网卡（如
eth0）不应直接加入 br0；它应属于另一个管理网桥（如br-mgmt），否则路由混乱
验证隧道连通性的三步法
别一上来就 ping 容器 IP，先确认隧道层是否活：
- 在 hostA 上执行：
tcpdump -i any udp port 8472 -nn -c 2，然后在 hostB 上ping -c1 <hostA的Underlay IP>—— 如果没抓到 UDP 包，说明 vxlan port 根本没发包，查ovs-vsctl show输出里vx1状态是否为connected - 在 hostA 上执行：
ovs-appctl fdb/show br0，看是否学习到了 hostB 上 VM 的 MAC（来自 vxlan port）；若为空，说明 VXLAN 解封装后的帧没进 br0，可能是 key/VNI 不匹配 - 用
ovs-appctl dpif/show查 datapath 级统计，重点关注vxlanport 的rx_packets和tx_packets是否增长；不增长=配置未生效或内核模块未加载
最常被忽略的一点：VXLAN 是无状态隧道，它不检查对端是否存在、是否在线、是否配置正确。哪怕 remote_ip 写错成一个关机 IP，ovs-vsctl show 依然显示 port 存在且状态为 connected。必须靠抓包或流表统计才能确认真实通路是否建立。
