前言
在日常运维中，总会遇到一些棘手的故障或问题，尤其面临多系统融合的兼容性或一些融合节点可能存在未知bug等方面，排错难度都会增加。
本文将从一次小事件为入口进行延伸，将宿主机esxi基础系统的多融合节点故障的排错历程展开介绍，并结合排错过程介绍esxi基础系统稳定性所依赖的环境条件。
排错阶段一：故障初现，随机复现
一、故障初现
事件背景： 某职场一天下午现场反馈有几个人无线网络连接不上
事件原因： 无线连网认证的网络认证服务器到某台AD域控网络不通，用户无法获取ad状态拒绝连网
临时措施： 重启网络认证服务器的网络服务，恢复
问题现象：
网络认证服务器到部分目标ip不通（其中一台AD域控属于其中）
网络认证服务器到部分目标IP通（告警系统属于通的ip，未产生服务器告警）
该esxi上部分虚拟机有类似问题，部分虚拟机正常
二、随机复现
疑问：为什么会出现这个问题，如何能够复现呢？
因为大部分核心业务系统都运行在esxi底层上，如何确认具体故障原因规避类似风险成为了重中之重。
1、抓包分析
与此同时，我们进行了该宿主机上的其他虚拟机详细检查，发现另一台虚拟机也存在部分ip不通的情况（本地服务无远程ip互通依赖，该虚拟机服务未受影响），根据该虚拟机进行了各链路节点抓包分析：
1、级联switch抓到了服务器发送的icmp reply包，但在上联核心switch未发现该reply包
2、为了排除server发出的包构造异常，使用了tcpreplay工具（一种pcap包的重放工具，可以将用ethreal、wireshark等工具捕获的网络数据包原样或经过任意修改后重放回去）在实验环境中进行了重写和重放，数据包正常发送接收证明了包构造正常（其实当时实验环境和故障环境有其他差异）
3、重启了交换机端口后，故障虚拟机恢复
当时结论：级联或上联switch有问题导致丢失数据包（该结论是误判）
2、复现尝试
虽有简单的结论，但需要复现故障才能确定具体问题环节！
在Esix排查过程中发现了故障时间节点有一条异常日志可能有关联性
Ixgben：indrv_uplinkreset：vmnic0 device reset started
查阅vmware相关论坛资料，发现了一条命令可以触发相同的日志出来（重要节点一）
VMkernel Sys Info Shell：vsish -e set /net/pNics/vmnic0/reset 1
使用该命令在故障环境中成功的进行了复现，但在测试环境中无法复现
当时结论：vmnic0的reset动作触发了故障，但满足故障发生的其他因素仍是未知
排错阶段二：环环相扣，错综复杂
疑问：到底是什么场景下，vmnic的reset动作会触发这个故障呢？
为了测试满足故障触发的X因素有哪些，我们尝试枚举了至少十几种有可能关联的条件，排列组合了十多套测试场景，用于测试确认
枚举X因素： 物理机型号、网卡型号、esxi版本、NLB模式、端口组配置、VSwitch配置、交换机型号、交换机系统版本、虚拟机OS、虚拟机数量，虚拟机角色，网段、服务器跳线等
在进行了不下于50次的排列组合测试后，不同的X因素之间有矛盾又有重合，而且复现的规律和频率不固定，无法稳定复现，但最终确定并缩小了一定的条件范围
当时结论：基本确定以下为触发条件范围（非最终）
服务器：Dell R740xd
网卡：Intel(R) Ethernet Controller 10G X550
驱动：ixgben网卡驱动
交换机：35系列交换机
虚拟机：linux
排错阶段三：稳定复现，找到关键
一、稳定复现
疑问：在这些条件范围中到底还有什么隐性因素可以决定故障能稳定复现呢？
在基本确定的触发条件范围中，有一项很特殊，为什么每次能复现故障的时候一定是linux虚拟机，而windows从未复现过。针对这一特殊性我们在排查过程中进行了重点关注，在多次组合测试后发现一个特征，出现问题的虚拟机在esxi底层显示虚拟机网络信息中SubType类型均为“6”（重要节点二）
经过资料查询确认了subtype=6代表虚拟网卡类型为vlance（ ”[AMD] 79c970 [PCnet32]” ），出现vlance类型的原因是早期创建linux虚拟机向导中选择了“其他linux系统”，esxi就会自动创建虚拟机网卡为vlance类型网卡
在实验环境中准备vlance类型网卡的虚拟机进行测试，最终“DELL机型+基于IP哈希+vlance”在reset vmnic动作触发下可以稳定复现，并且复现的虚拟机到多个目标网络的测试是一半通一半不通，其中非“基于IP哈希”的NLB模式无法复现
二、找到关键
疑问：稳定复现后，如何确定是哪一环节导致部分通部分不通呢？
与此同时，网络组在升级cisco厂家售后工单等级后，在资深售后的协助下，通过EPC（Embedded Packet Capture，一种嵌入式的抓包工具，有更强的灵活针对性，特别适用于网络排障和在线抓包的情况）多次抓包分析得到一个重要信息，当虚拟机出现问题的目标ip到达switch接收包vlan tag为0，当虚拟机的正常目标ip到达时vlan tag则为正常的id号（重要节点三）
当时结论：出现故障时因接收到的是没有正确标注VLAN ID的数据包导致三层交换无法转发
排错阶段四：拨云见日，水落石出
一、拨云见日
1、确认故障因素：
疑问：是什么因素导致了vlan tag异常？
有了vlan tag丢失这个关键因素，我们对比了vmware官网中各个esxi版本的更新介绍，其中在6系列相关版本中均提到了有vlan tag相关的bug描述，并给出了临时处理方案，另在7.0版本中说明修复了该bug
在实验环境中复现故障后，根据vmware的临时方案如愿恢复了故障
针对该方案命令的一些参数进行分析研究，命令效果是在esxi的底层网络部分将vlan相关的功能重启了一下（类似我们重启了网卡或交换机端口等操作）
另外我们将实验环节中的esxi升级为7.0后，该故障也无法复现了
当时结论：验证了vlan tag丢失导致问题，但该bug暂无详细说明
2、确认故障环节：
疑问：问题好像找到原因了，但是到底哪个环节导致vlan tag丢失了呢？
从虚拟机到switch还要经过Esxi层多个网络环节：虚f拟机，端口组，vswitch，物理网卡
通过esxi底层的pktcap-uw抓包工具（高级版的抓包及分析工具，主要应用在ESXi 5.5以后的版本中）对esxi底层三段网络链路进行了同时抓包
测试场景结果虚拟机到端口组数据包正常，vlan tag正常端口到vswitch数据包正常，vlan tag正常vswitch到物理网卡数据包正常，vlan tag正常物理网卡到交换机数据包正常，vlan tag异常
当时结论：物理网卡导致了vlan tag丢失
二、水落石出
1、确认故障原因：
疑问：物理网卡为什么会导致vlan tag丢失？
根据DELL机器所搭配的万兆网卡X550的特性进行资料搜索，我们在lenovo的官方论坛中找到了一篇关于10G ixgben网卡在1.8.7驱动版本中修复了vlan tag相关bug的说明，我们的版本是：1.7.10(重要节点四)
于是我们将故障宿主机的网卡驱动升级到了高版本进行测试，故障场景无法再复现
为了进一步确认关联性，又进行了多次组合测试
测试场景结果将故障宿主机的绑定线路换到千兆网卡无法复现将esxi6.*升级到8.0（此时网卡驱动自动升为1.13.10）无法复现将esxi8.0的网卡驱动降级为1.7.10故障复现将万兆X550（1.7.10）网卡安装在HP服务器中故障复现
至此，在整个排错过程中不同环节的疑问都得到了合理的解释
疑问1、 为什么同样的DELL宿主机型号和vmware配置和网络配置，有的复现，有的不能复现？
此类故障影响的是网卡为vlance类型的虚拟机
疑问2、 为什么同一台宿主机linux出故障，windows不出故障
故障linux属于vlance类型网卡（当安装操作系统时选择版本“其他”引起），windows属于E1000网卡
疑问3、 为什么将负载均衡模式调整为其他非“基于ip哈希+trunk”模式，就不能复现
因为“基于ip哈希+trunk”工作模式涉及网络层打vlan tag，触发ixgben1.7.10版本驱动bug问题，其他的搭配如：基于ip哈希+access，基于源虚拟端口，基于源mac等负载均衡模式均不涉及网络层vlan tag
疑问4、 为什么虚拟机出现故障时到目标ip是一半通一半不通
基于ip哈希的算法会对源及目标ip进行哈希计算分配不同的物理链路，当reset其中一块网卡时，一半目标受影响
疑问5、 为什么hp的宿主机不能复现
hp宿主机没有搭配x550的万兆网卡（ixgben1.7.10）
疑问6、 为什么将esxi的tagging设置为开启不作为根本解决方案
因为开启后，类似于开启混杂模式。将会暴露更多的安全风险
疑问7、 为什么本次遇到的vlan tag丢失不属于esxi6.7的版本bug（官方有说7.0修复类似bug）
因为采用esxi高版本搭配ixgben1.7.10依然可以复现
总结：
通过完整的排错下来，最终确定了引起该事件的根本原因，以下四个条件同时满足会触发该类故障
条件一： 使用驱动ixgben 1.7.10的X550网卡
条件二： 采用“基于IP哈希”的负载均衡模式
条件三： 虚拟机虚拟网卡型号为“vlance”
条件四： ESXI的vmnic发生reset动作
眼见不一定为实，在复杂的故障场景分析中，会有很多的干扰因素影响着我们的判断，通过不断的排列组合去在差异中找共性、在共性中找差异是一种剔除干扰信息的方法之一；抱着去伪存真精神找到问题背后的根源，才能提供更有效的解决方案。