网络虚拟化故障排查：从VM通信中断到VXLAN隧道不通的实战思路

上周帮运维同事处理一个典型问题：某台宿主机上的3台虚拟机突然全部无法访问外网，但同宿主机其他虚拟机一切正常。登录后发现，这三台VM的vNIC在Open vSwitch里显示状态为link-down，而物理网卡bond0和上行链路都亮着绿灯——典型的“看得见、连不上”。

先看三层通不通

别急着重启ovs或者重装agent。先确认基础路径是否跑得通：
进宿主机，用ip link show查一下对应的veth pair是否存在；再用ovs-vsctl list-ports br-int核对端口是否还在桥上；最后执行ovs-ofctl dump-flows br-int | grep "dl_src=<VM_MAC>"，看看流表里有没有匹配这条MAC的转发规则。

VXLAN隧道断了？抓包定位最直接

如果虚拟机跨宿主机通信失败，大概率是VXLAN隧道没建起来。在源宿主机执行：

tcpdump -i any port 8472 -nn -c 10

同时在目标宿主机也抓一遍。两边都没包？说明控制面没下发隧道信息，检查Neutron server日志里的ml2 plugin初始化是否报错；只有一边有包？多半是UDP 8472被防火墙拦了，或底层网络ACL策略没放开。

别忽略MTU这个“隐形杀手”

某次迁移后所有虚拟机SSH连接频繁卡顿，ping延迟忽高忽低。查了一圈发现，物理交换机MTU设的是1500，而VXLAN封装后实际帧长超了，导致分片。临时解决办法是在宿主机上把OVS内部端口MTU调小：

ovs-vsctl set interface vxlan0 mtu_request=1450

长期方案是统一整条路径MTU（物理网卡、交换机、OVS端口、VM网卡），建议设成9000（jumbo frame）或至少1450。

NSX-T里常见陷阱：Segment和Transport Zone不匹配

客户部署NSX-T时，新建的Tier-1路由器下挂虚拟机始终获取不到IP。翻遍DHCP日志都没请求记录。最后发现：该Segment绑定的Transport Zone和Host Transport Node配置的TZ类型不一致——一个是OVERLAY，另一个是VLAN。NSX-T不会报错，但根本不会转发流量。用get transport-node和get segment命令比对TZ ID就能快速揪出。

排障口诀记两句话

第一句：“先查链路层，再看控制面，最后动数据面”。veth消失、port未注册、ovsdb连接断开、控制器失联……顺序错了容易绕弯子。
第二句：“改一点，验一点，留日志”。比如调整QoS限速策略后，立刻用iperf3测带宽，同时ovs-appctl dpif/show看对应端口计数器变化，别等一堆改动堆一起才回头找哪步惹的祸。