OVS连接虚拟机网络不通如何排查，虚拟机网络不通怎么解决

OVS连接虚拟机后网络不通，问题大概率出在流表、端口状态或物理链路这三处，按顺序逐层排查就能找到症结。

OVS虚拟机网络不通怎么排查先看这三张表

虚拟机接入OVS却ping不通，多数朋友第一反应是重启网络服务，或者重建端口，其实最稳妥的路径，是从OVS自己的视角先确认三件事：端口在不在、流表通不通、接口状态对不对。

第一步：端口有没有真正挂到OVS上

用ovs-vsctl show查看当前所有桥接器和端口列表，重点看虚拟机对应的tap口或vnet口是否出现在某个bridge下，行业共识认为，相当一部分“网络不通”其实是虚拟机的网卡根本没插进OVS。

如果端口列表里没有虚拟机接口，检查宿主机上的ip link，确认TAP设备是否存在，如果TAP设备存在但OVS里不显示,手动添加：

ovs-vsctl add-port br-int vnet0

添加完用ovs-vsctl list-ports br-int验证，端口出现在列表里,才算第一步通过。

第二步：流表是否命中了VM的流量

OVS的核心是OpenFlow流表，所有转发决策都靠它，一个常见场景是：端口在列表里，但虚拟机依然不通因为流表下发了错误规则,或者根本没下发。

查看某个bridge的流表：

ovs-ofctl dump-flows br-int

重点看有没有匹配虚拟机MAC地址或IP地址的流条目，如果一条都没有，说明控制器（比如OpenStack Neutron的Open vSwitch Agent）没正常下发流规则，尝试重启Agent服务,或者检查OpenStack日志里的异常信息。

如果流表存在但虚拟机还是不通，用ovs-ofctl dump-ports br-int确认端口统计信息，看是否有报文进出，但凡tx_packets一直在涨，rx_packets始终为0，说明OVS层面根本没收包,问题在上游。

第三步：接口状态是否UP

端口存在、流表正常，还要确认接口状态,执行：

ovs-vsctl get Interface vnet0 ofport

拿到OFPort号后，用ovs-ofctl show br-int查看该端口的状态，如果显示OFPPC_PORT_DOWN，说明端口被标记为down,直接UP它：

ovs-vsctl set Interface vnet0 options:up=true

或者从虚拟化平台侧重置网卡状态，很多情况下，做完这一步,虚拟机立即就能恢复网络。

OpenStack环境OVS虚拟机网络不通的高频原因

在OpenStack这类云平台里，OVS虚拟机网络不通的排查路径略有不同，因为引入了Network Namespace、安全组和隧道封装，以下几个原因值得优先排查,因为它们占比较高。

安全组规则把流量拦在门外

虚拟机的安全组默认拒绝所有未经允许的流量,排查时先确认安全组是否放通了ICMP协议和SSH端口。

通过命令行查看虚拟机对应的安全组：

openstack server show <vm-id> -c security_groups

如果安全组确实没放通，不要直接删除安全组那会被审计追责，正确做法是创建一条允许ICMP和TCP/22的规则，然后动态添加给虚拟机。云平台的安全组状态是实时生效的,添加规则一般几秒内就能让网络恢复。

DHCP命名空间和元数据服务异常

OpenStack的虚拟机多半靠DHCP获取IP，而DHCP服务跑在独立的Network Namespace里（比如qdhcp-xxx），如果这个Namespace挂掉，虚拟机拿不到地址,自然ping不通。

检查DHCP Namespace是否存在：

ip netns list

再确认dhcp-agent进程状态,尝试重启：

systemctl restart neutron-dhcp-agent

如果虚拟机一直停留在“获取IP中”的状态，多半就是这里出了问题，另外元数据服务（Metadata Service）异常不会直接导致网络不通，但会影响cloud-init的启动，最终让网卡配置落下比如eth0根本没配置IP。

VLAN或VXLAN隧道封装不匹配

跨节点通信依赖隧道协议，VXLAN模式下，每个宿主机的br-tun负责对流量做VXLAN封装和解封装，如果两端的VNI配置不一致，或者VTEP地址路由不通,虚拟机之间的流量就会在半路丢失。

在宿主机上查看：

ovs-vsctl show | grep -A5 br-tun

对比两个节点的Local IP和VNI配置，再ping一下对端的VTEP地址，如果VTEP地址ping不通，说明物理网络或路由表有洞顺着这个方向查,比在OVS内部瞎转高效得多。

OVS和Linux Bridge的区别，决定了排查方向

搞明白OVS和Linux Bridge的区别，对排查本身就很有帮助，两者虽然都在做二层交换,但设计思路完全不同。

举个例子，Linux Bridge下虚拟机不通，查MAC地址表就完了；而OVS环境下，除了MAC地址表，还要排查流表的match字段是否精确匹配。OVS的出问题链路更长，但排查工具也更丰富它自带trace工具,可以直接追踪某个报文的完整路径：

ovs-appctl ofproto/trace br-int in_port=vnet0,dl_dst=fa:16:3e:xx:xx:xx

这个命令能告诉你报文是否命中流表、是否被drop、最终从哪个端口出去,是全网公认最有效的OVS排查利器。

从虚拟机到物理网卡的逐层排查清单

排查思路僵化的时候，建议按层次从内到外过一遍，每一层都有一个明确的操作命令,照着做就行。

虚拟机内部检查

先确认虚拟机自己的状态：

ip addr show eth0
ping -c 3 网关IP
arp -n

网关ping不通，检查网卡配置文件里的BOOTPROTO和IPADDR，确认没有配错网段，如果用的是cloud-init模式，确认元数据服务能访问curl http://169.254.169.254/latest/meta-data才算正常。

OVS内部检查

宿主机上执行：

ovs-vsctl show
ovs-ofctl dump-flows br-int | grep <vm_mac>
ovs-ofctl dump-ports br-int | grep <ofport>

再看一下端口的学习MAC地址表：

ovs-appctl fdb/show br-int

如果虚拟机MAC地址没有出现在fdb表里，说明OVS根本没收到虚拟机发出的任何帧,问题大概率在虚拟机的网卡驱动或虚拟化平台侧的设备模型上。

物理链路检查

OVS的external接口（通常是eth0或bond0）负责和物理交换机互联，检查这个口有没有UP、有没有丢包：

ethtool eth0
ip -s link show eth0

如果物理网卡的RX errors在持续增长，说明物理链路上存在故障，再到物理交换机上查这个端口的trunk配置，确认放行的VLAN列表包含虚拟机所在VLAN，很多跨节点不通的场景，罪魁祸首就是物理交换机端口上没放通对应的VLAN。

最后抓包验证：

tcpdump -i any icmp -n

在OVS所在宿主机的任意接口抓包，看ICMP请求是否到达宿主机，如果连宿主机都没看到请求包，问题在虚拟机到宿主机之间；如果看到了请求但回复包发不回去,问题在OVS流表或路由配置上。

关于OVS虚拟机网络不通常见的三个问题

Q：OVS虚拟机关机后网络不通怎么回事？

虚拟机关机再开机后网络不通，一般是虚拟化平台和OVS的同步出了问题，重启后，虚拟机的网卡设备重新注册，但OVS端口可能没自动恢复attach，优先检查ovs-vsctl show里该虚拟机对应的接口是否存在，不存在就重新添加，注意确认新接口的MAC地址和之前一致,否则流表里的匹配规则永远不会命中。

Q：OVS和Linux Bridge切换后虚拟机突然无法上网？

从Linux Bridge迁移到OVS后，现有的虚拟网卡是通过Linux Bridge加载的，接口名和驱动不兼容，最直接的验证方法是把虚拟机的网卡拆掉重新添加，让虚拟化平台重新生成设备，如果OVS里的端口状态和流表都正常，但虚拟机仍然不通，去查虚拟机镜像内的网卡配置文件,确认没有绑定旧接口名称。

Q：宿主机重启后OVS虚拟机网络全部瘫痪？

宿主机开机后OVS服务若没正确拉起，所有虚拟机的网络都会中断，先执行systemctl status openvswitch确认服务状态，再ovs-vsctl show检查之前的桥接器和端口是否恢复，个别版本在开机时不会主动恢复端口，需要手动重跑一次ovs-vsctl add-port，建议检查系统是否启用了openvswitch-switch的自启动,并把相关的Agent服务一并加入开机启动项。