今天上午刚上班的时候突然接到任务，说是有个企业的ESXI系统里的虚拟机访问不到了。于是我跟着同事和技术主管一起赶过去，那个企业还挺远的，开车开了一个半小时才到。

问题描述

到现场以后企业的人进行了问题的描述，导致这次问题的原因是因为两天前短了一次电。服务器再开起来的时候EXSI和vCenter都可以正常访问，但是其内部的虚拟机无法访问。听到描述以后我的脑子里闪出来一个大致的方向：“应该是业务口和网络设备连接的问题。”于是我找到企业那边负责网络的人，不问不知道一问吓一跳，你猜咋着，他们不知道服务器是接在哪个交换机上的，而且也不知道交换机的帐号和密码。真的给我开了眼了....

随后没什么办法，只能先从vCenter上面入手了，看看有没有什么虚拟机没开机，网卡设置错误的问题。经过一段时间的排查修改以后，最终出现了一个看起来比较玄学的问题：在同一个ESXI主机上的同一个虚拟交换机上的同一个端口组下的虚拟机，有的可以Ping通有的Ping不通。而且虚拟机的网卡均为开启状态且配置正常。

解决流程

首先第一步，登到Ping不通的虚拟机中看一下它能不能ping到自己的网关。

结果是Ping不通。

接着查看别的Ping的通的虚拟机能不能Ping到自己的网关。

结果是可以通。

所以这就不存在网关禁Ping和端口组不可达网关的情况。

接着第二步，分析上层链路。

既然ESXI这边的内容都是一样的且没有配置错误，那就说明是上游的问题导致的。

所以经过讨论以后直接从服务器接了几根网线到核心交换机上，核心交换机他们知道密码，而且也能规避掉接入层和汇聚层配置错误的风险。

接入到核心交换机后问题依旧，有一些虚拟机能Ping通有一些Ping不通。

第三步，查看核心交换机是否存在策略阻拦。

现在是同一个网络下有的能通有的不能通，这个情况的最大可能的因素就是在核心上配置了策略，有的虚拟机IP被放通了有的IP没有被放通，导致有的能Ping到网关有的Ping不到。

于是通过ARP查能Ping通的虚拟机走的哪个VLAN，找到VLAN后查看那个VLAN绑定到哪个接口以及ACL策略。

经排查发现VLAN绑定了一个ACL策略，且确实存在策略阻碍流量的问题。在ACL中添加permit ip source 虚拟机网络后发现在虚拟机中可以Ping通网关了。

但是还存在一个问题，就是无法从终端Ping通虚拟机，这也就是说肯定又有策略阻碍了从终端网络到虚拟机网络的流量。

为了排查简单以及业务快速上线，在核心上对应WIFI的ACL直接放通了所有的网络流量到服务器的流量（此操作存在极大的安全隐患，测试业务成功上线后需迅速细化ACL颗粒度）。

配置完成后终端设备成功Ping通虚拟机，业务成功上线。

总结

这次故障排查得到了几个宝贵的经验。

不要上来就开始按照自己的想法开始解决问题，先沉下心来仔细看看错误的情况以及导致问题出现的原因，要不是刚开始在主管旁边看着主管去慢慢查看事故具体情况我也不会这么快能定位到问题。
因为通信导致的问题可以先从里面Ping网关，解决了从里面到网关的问题身下的就是从终端到网关了。如果不允许操作里面的虚拟机可以用网关Ping虚拟机。
想要查看服务器接入到交换机上的哪个网口可以查看用服务器IP地址arp地址表，里面写了从哪个接口获取到的地址。