openstack虚拟机不通，绝大多数逃不出这三层：安全组、DHCP/路由器、L2物理链路，排查时按“从虚到实”的顺序一层层剥，通常十分钟内就能找到问题。
先说清楚一个原则：虚拟机不通不一定都是openstack的锅。先别急着翻配置，先搞清楚“谁不通、通到哪、什么时候开始不通”，故障范围决定了排查方向,方向错了只会越查越乱。
openstack虚拟机网络不通排查：先分清故障范围
- 只有一台虚拟机不通：问题大概率在虚拟机自身，或者它绑定的安全组、端口属性。
- 同一项目所有虚拟机都不通：重点查路由器和DHCP命名空间。
- 所有项目的虚拟机都拿不到IP：考虑网络节点上的neutron服务,以及底层物理网络。
从虚拟机内部看网络状态
登录虚拟机，执行下面三条命令，能过滤掉一多半的“假故障”：
ip addr：看网卡有没有IP，如果是169.254.x.x,说明DHCP没拿到地址。ip route show：看默认网关是否存在,有时候多网卡虚机会把默认路由指错。ping -c 3 网关IP：测一下到网关的二层连通性。
如果虚拟机内IP、网关都正常，但ping网关不通，这时候再往虚拟网络层去查。不要一上来就重构网络，那是最后一步。
创建虚拟机后ping不通网关？先看这两层
- 第一层：安全组有没有放行ICMP，openstack默认安全组通常只放行内部几个常见端口，很多镜像创建出来的虚拟机,入方向根本没有ICMP规则。
- 第二层：虚拟机的端口有没有绑定到正确的子网，用
openstack port list查看fixed_ips，如果IP没落在目标网段,网关自然不可达。
检查方法很简单：在控制节点上执行 openstack security group rule list <安全组ID>，看看有没有 protocol=icmp 的入方向规则，没有的话,加上就行。
安全组配置是openstack虚拟机不通的高发原因
业内专家指出，安全组配置错误占了openstack虚拟机网络不通原因的相当一部分，而且这类问题最隐蔽,因为不查规则根本想不起来。
入方向规则写反：ICMP没放行
很多人在openstack上创建安全组时，只添加了TCP端口，比如22、80，然后就开始ping虚拟机，ping用的是ICMP协议，TCP规则不覆盖它，结果就是SSH能通、ping不通。
临时验证方法：
openstack security group rule create --protocol any <安全组ID>
放行所有协议。
- 放行后再ping，如果通了,基本能确定是ICMP规则缺失。
正式修复就补一条入方向ICMP规则，来源IP可以限制在办公网段或VPC网段,别直接全开。
规则之间没有优先级，只有放行和未放行
Neutron的安全组规则是“或”关系，只要有一条匹配就放行，不存在“拒绝优先”的说法，很多人会以为放行了所有端口就能解决一切，其实不对：如果某条规则的协议类型是TCP,ICMP照样会被丢弃。
所以排查时要把规则按协议拆开看：
- ICMP规则单独一条。
- SSH/TCP规则单独一条。
- 如果有UDP业务,也单独放行。
这样不仅清晰，还能避免“放行All traffic”带来的安全风险。
DHCP与路由器命名空间异常：中大型故障的根源
当一批虚拟机同时出现网络问题时,重心要转移到网络节点上的命名空间。
dnsmasq进程状态检查
DHCP服务实际上是跑在qdhcp命名空间里的dnsmasq进程，dnsmasq挂了，虚拟机就拿不到IP,或者拿到的是过期租约。
排查步骤：
- 在网络节点上执行
ip netns list,看看有没有qdhcp开头的命名空间。 - 找到对应网络的命名空间，执行
ip netns exec qdhcp-xxx ps aux | grep dnsmasq。 - 如果dnsmasq不存在，查看
/var/log/neutron/dhcp-agent.log和dmesg输出。
修复方式通常是重启neutron-dhcp-agent服务，如果重启后dnsmasq仍然起不来，查看租约目录 /var/lib/neutron/dhcp/ 下是否有残留的租约文件,清理后重启。
qrouter状态与SNAT规则
跨网段通信和访问外网都要经过qrouter命名空间，qrouter状态异常，最典型的表现是虚拟机之间互访正常,但访问外部网络全部超时。
检查命令：
openstack router show <路由器ID>,看status是否为ACTIVE。- 在网络节点上执行
ip netns list,确认qrouter命名空间存在。 - 执行
ip netns exec qrouter-xxx iptables -t nat -L POSTROUTING,查看SNAT规则是否还在。
行业共识认为，网络节点上命名空间意外丢失，或者系统重启后neutron进程没有完全拉起，是导致批量虚拟机不通的重要原因，遇到这种情况，不用犹豫，直接把路由器重建一次,比手动修复来的快。
物理网络和L2 Agent问题：小包通大包不通的蛛丝马迹
有时候虚拟机本身配置没问题，安全组也放行了，但网络就是不通,这时候需要看二层转发和物理链路上的匹配情况。
Open vSwitch流表检查
计算节点上的neutron-openvswitch-agent负责维护br-int和br-tun的流表，流表如果没同步，虚拟机的流量到了br-int就断了。
检查思路：
- 在计算节点上执行
openstack network agent list，确认openvswitch-agent状态为UP。 - 执行
ovs-vsctl list Port找到虚拟机对应的内部端口。 - 执行
ovs-ofctl dump-flows br-int | grep <端口号>,看是否有对应的流表项。
如果流表缺失，重启openvswitch-agent通常能触发重新同步，但如果链路不稳定，重启后会反复掉线,这时要检查物理网卡和bond状态。
MTU不一致导致大包丢包
这个现象很经典：小包ping得通，大包ping不通，网页打开也卡,原因多半是隧道网络MTU和虚拟机接口MTU不匹配。
openstack VXLAN隧道默认MTU是1450，而虚拟机的网卡默认是1500，物理链路MTU不够时，大包会被丢弃,小包因为没超过限制所以正常。
验证方法：
- 在虚拟机内执行
ping -M do -s 1400 <网关IP>,能通则说明链路OK。 - 再把包大小增加到1472,如果不通则确认是MTU问题。
修复方式是在创建时不指定路由器MTU，或统一将网络MTU调整为1450，注意物理交换机上对应端口的MTU也要同步支持,否则同样会丢包。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 小包通、大包不通 | 链路MTU不匹配 | 比对虚拟机、路由器和物理交换机MTU |
| 单台虚拟机IP获取不到 | dnsmasq异常或租约冲突 | 查看qdhcp命名空间和dhcp-agent日志 |
| 所有虚拟机外网不通 | qrouter中SNAT规则丢失 | 检查qrouter的iptables规则 |
虚拟机关联安全组后仍然不通的自身原因
云平台层面的安全组和路由检查完都没问题，那就要“钻进”虚拟机内部找原因。
系统内防火墙和路由表拦截
很多镜像默认开启了内部防火墙，比如Ubuntu的ufw、CentOS的firewalld，云平台安全组放行了，但虚机内部的iptables不放行,一样不通。
检查命令：
iptables -L -n查看INPUT链和FORWARD链。- 临时清空iptables规则测试连通性（谨慎操作，建议在测试环境验证）。
- 查看虚拟机内路由表：
ip route show,确认默认路由指向正确的网关。
如果是双网卡虚拟机，还要检查策略路由，只有一个默认网关时,另一张网卡很可能无法访问外部。
元数据服务影响网卡初始化
云平台镜像需要通过 http://169.254.169.254 获取metadata，如果这个地址在虚拟机的路由表里缺失，cloud-init可能会卡住,导致网卡初始化不完整。
检查方法：
ip route show | grep 169.254.169.254看看有没有指向eth0的metadata路由。- 如果缺失，手动添加：
ip route add 169.254.169.254/32 dev eth0。
这个原因不算高频，但一旦碰上，表现就是虚拟机起不来或者网络服务启动失败,排查起来很费时间。
写在最后
openstack虚拟机不通的问题,总结下来就是三句话：
- 先查安全组放行方向,这是最容易踩的坑。
- 再查DHCP和路由器命名空间,批量不通时优先看这里。
- 最后查OVS流表和物理链路,特别是MTU不一致导致的大包丢包。
遇到问题不要慌，按这个顺序一步步来，大部分openstack虚拟机网络故障都能在半小时内定位，把常用命令打印出来放在手边,比任何监控工具都管用。
openstack虚拟机不通是什么原因：常见Q&A
Q1：openstack虚拟机网络不通排查时，安全组和虚拟机内防火墙哪个先查？
先查安全组，安全组是云平台层面的第一道关卡，它会直接反应在宿主机的iptables规则里，如果安全组没放行，就算虚拟机内部防火墙完全开放，流量也进不去，安全组确认无误后，再查虚拟机内部防火墙,顺序不要颠倒。
Q2：创建虚拟机后ping不通网关，但外网能通，这是为什么？
外网能通说明路由器和SNAT工作正常，ping不通网关有两个常见原因：一是安全组入方向没有放行ICMP，二是端口的允许地址对（allowed-address-pairs）没有包含网关的MAC和IP，先检查安全组ICMP规则，再执行 openstack port show <端口ID> 看allowed-address-pairs字段。
Q3：所有openstack虚拟机突然都不通了，最可能是什么原因？
最可能是网络节点上的neutron服务异常，或者底层物理交换机链路故障，先在网络节点上执行 ip netns list 核实qrouter和qdhcp命名空间是否存在，再用ping测试网络节点与计算节点之间的隧道IP，如果这两项正常,直接检查物理网卡链路状态和交换机端口。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/611905.html
