问题背景
为了解决节点上请求部分service延迟63s问题[1]，我们临时把OS的版本换成了Redhat 8.4（内核版本4.18.0-305），在VMware上虚出3节点集群后部署跨三层环境失败，提示Harbor部署失败。
原因分析
说明：距离定位这个问题已经有一段时间了，其实最终也没完全定位出根本原因，所以当时也没有整理记录定位过程，这里就简单描述一下，做个记录。
通过查看Harbor的日志，发现部署失败的原因是健康检查失败，因为Harbor的podIp:port请求在跨三层下超时，抓包发现请求经过vxlan.calico时止于SYN_SENT报文；
实测发现，该环境上不仅是Harbor的podIp:port请求超时，其他pod服务的请求经过跨三层的网络也同样存在问题，说明是一个共性问题，并且pod网段的七层如http请求受影响，4层的icmp请求不受影响）；
继续通过抓包确认，podIp:port的请求已经发送到节点网卡上，但跨三层对端的节点没有收到。所以，可以排除主机上的iptables和路由的影响。实际上，也确实跟踪了iptables的请求过程，确认请求没有被丢弃；
综上，初步怀疑请求被跨三层网络的中间设备（如交换机、路由器）丢弃了，之后相关同事在交换机上抓包，发现ping包可以抓到，但http请求依然抓不到，说明交换机侧也没有收到报文，问题原因进一步缩小，可能情况有：
通过ehtool -s xxx命令统计虚机网卡报文信息，没有发现丢弃情况，说明问题不在虚机的出网卡；
关于VMware丢弃报文的情况，找到一些资料[2-6]，比如混杂模式，mms配置都会有影响：
1) 通过ping命令指定报文长度，发现跨网段依次ping一下pod的ip均返回正常，确认不是mms问题; ping -s 1000 177.177.x.x ping -s 1472 177.177.x.x ping -s 1500 177.177.x.x 2) 通过临时修改网卡为混杂模式，测试问题依然存在;
进一步在服务器物理网卡上抓包（登录esxi后台，使用pktcap-uw –uplink vmnicX –dir 2 -o result.pcap，其中vmnicX表示虚机关联的上行口物理网卡, dir 2表示同时抓取双向请求）, 依然是ping包可以抓到，但http请求依然抓不到，说明服务器物理网卡上也没有收到报文；
最后，丢包范围缩小到VMare下的虚机机请求出网卡后，到服务器物理网卡前 ，这中间涉及到虚拟化的实现，具体还有什么处理就不清楚了，最后改为使用物理服务器部署；
解决方案
临时改用物理服务器部署跨三层集群成功，如果要使用VMware虚机部署，还需要继续排查根因。
