今天的题目是关于NSX的虚拟网络故障分析，问题排查定位的经验分享，严格地说，不属于终端用户计算的范畴，但是终端用户计算以及软件定义的网络已经结合得越来越密不可分，有越来越多的用户开始使用NSX搭建EUC产品的专有网络环境，例如给VDI的计算资源池分配专有的网络空间，参见之前的博客利用NSX搭建专有子网。

笔者最近也搭建了一套基于NSX虚拟网络的EUC实验环境，通过使用NSX提供的logical network的能力，可以随心所欲的构建自己的网络，互联互通，网络微分段，分布式防火墙，完全不必麻烦公司的网络管理员，真的是我的地盘我做主。既然是自己的地盘自己做主，当然出了问题也要自己搞定，不能麻烦网管了。在这里我就和大家分享一个我最近碰到的一个网络故障，问题排查的过程还是蛮有趣的，希望给大家提供一点碰到虚拟网络问题后的解决思路，可以举一反三。

首先的我的实验环境的网络架构类似如下图

图一

该实验环境由5台服务器构成，包含3个集群，每个集群上分别放置EUC相关的产品组件。

因为是实验环境，有两个集群managementcluster, Network Cluster只包含一台服务器。当然在生产环境中，一个集群至少要包含两台服务器才能保证高可用。

图二

那么说一下我碰到的问题，某天下午我还在自己的实验环境中正常工作，比如可以从位于内网192.168.100.0/24上的vm1正常地访问外网192.168.99.0/24，到了晚上的时候，却发现所有的位于内网192.168.100.0/24上的虚拟机都不能访问外网了。

事出突然，必有妖孽。第一反应是南北方向的网络通道上的路由可能被损坏了，因为该环境还有别的同事正在做别的实验，先让别的同事停止在该环境中的操作，排除其它因素的干扰。然后我梳理了一遍Distributed Logical Router以及Edge Gateway上的各项设置，没有发现任何异常的地方。

没有任何头绪，我索性按照http://www.virtualizationblog.com/nsx-step-by-step-part-16-configuring-static-route/ 在相同的硬件环境上又重新搭建了一个类似的网络环境，在这个新的网络环境中，虚机依然不能访问外网资源。

利用ping,tracert等工具，发现在内网的每一个虚机都能够访问内网网关192.168.100.1,也能够访问transition 网络上的下行端口10.10.10.2，但是transition 网络上的上行端口10.10.10.1就访问不到了。这种现象让我依然认为是南北向的路由出了问题，我试着定位路由在那里断掉了，依然没任何头绪。

浪费了大半天时间，我又试着看一下东西向的网络通讯。我发现同在一个内网192.168.100.0/24上的虚拟机之间有的彼此能够互相通讯，有的却彼此不能通讯，这让我怀疑可能是NSX构建的虚拟网络出问题了，例如VXLAN Tunnel End Point所用的IP被别人占用了之类的，查了一下也排除了这个可能。又开始读官方的问题解决手册https://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_troubleshooting.pdf ，块头太大，没有完全读完，也没能按照其中的步骤去定位问题。事后想想这个文档还是蛮有用的，按照其中的办法挨个子系统分别排查，自底向上，应该能够找到故障原因的。

回过头来，又开始看东向西的通讯，想从某些虚机彼此能够互相通讯，某些虚机彼此不能互相通讯的现象中找出一些规律出来。结果真找出来一个规律来： Management Cluster和Workload Cluster里面位于内网192.168.100.0/24上的虚机彼此可以相互通讯，但是都不能和Network Cluster里面位于内网192.168.100.0/24上的虚机通讯。如图一中所示，vm1,vm3,vm4,vm5可以互相通讯，但是不能和vm2通讯。因为南北向所有的网络节点组件也都是位于vm2所在的物理服务器上，貌似是所有位于ESXi服务器192.168.99.12上的虚机都变成了网络的孤岛。从这个现象，开始合理地怀疑该机器上网络接口出现了问题。

在我的实验环境中的每一台服务器都有四个网卡接口，其中第一块网口都用作ESXi的vmkernel接口，这一块网卡肯定没有坏，否则我根本不能通过vCenter来访问vm2。

图三

NSX的虚拟网络都是架构在vSphere的分布式网络交换机基础之上的，分布式网络交换机可以给加入其中的每一个物理主机分配不同的物理网卡作为上行接口。虚拟网络192.168.100.0/24在Vm2所在的物理主机上使用第二个物理网口NIC2作为上行接口。

图四

合理怀疑以后，就需要实事求证了。和Luke同学商量了一个反向求证的办法：配置vm2所在的物理主机上的ESXi管理网络的物理网络接口，缺省的配置是NIC1,依次将网络接口改成NIC2,NIC3,NIC4,然后观察vCenter中ESXi主机的连接情况，如果该物理主机在vCenter显示失去连接了，这就表明该物理网口出问题了。

图五

一番求证工作做下来，果然证明该服务器上的NIC2,NIC3,NIC4三块网卡都出问题了。三块网卡硬件都出问题，这么邪门的事情都让我碰上了,看来我可以去买彩票了。不过不得不说，vmware的软件还是靠谱的，一台服务器上的硬件坏了，分布在其余服务器上的虚拟网络依然正常工作。

剩下的工作就简单了，抄起电话找IT工程师更换网卡，问题搞定，我又开始在我的地盘里折腾了。

希望我这次故障分析，排查，解决的思考过程能够对大家有所帮助。

关于作者：Sam Zhao，EUC解决方案部门经理。在软件开发，测试，项目管理,客户项目实施，Technical marketing方面有15年IT从业经历，发表过七个专利以及合著书一部。

本文出自 “VMware终端用户计算” 博客，请务必保留此出处http://vmwareeuc.blog.51cto.com/8606576/1921971

NSX 虚拟网络故障分析经验分享