本文转载自微信公众号《小霸王》，作者小霸王。转载本文请联系小霸总裁公众号。写在前面：最近有个保险客户急急忙忙的来找我说：“韬哥，我们批处理过程中每天晚上经常报错，10万个HTTPPOST请求中，大概有6个700请求失败，失败现象随时可以重现，请速帮我。”经老中医把脉，梳理了整个出差流程，我想出了良方，辅以猛药，基本治好了病。由于这种故障场景非常具有代表性，特整理出此文，希望能给大家在日常运维排查中带来一些启发。话不多说，干货。Networklogicaltopologyandserviceflow：服务的逻辑拓扑图，如下图所示。批量业务服务器：Server110.160.XX.81:8000，Server210.160.XX.82:8000。并通过前端F5设备提供负载均衡和业务发布，VIP地址：10.50.XX.67:8165。测试端：通过curl向F5VIP10.50.XX.67:8165发送POST请求（批处理）接入过程：用户使用脚本通过curl向F5VIP10.50.XX.67:8165发送POST请求POSTrequest根据负载均衡算法将请求转发到真实服务器Server1或server2。F5与服务器之间有一台国产XX信NGFW设备（上行F5设备使用防火墙的feth11接口，下行交换机使用防火墙的feth10接口）。说明分析数据包时会提到防火墙的入接口和出接口。现象：用户使用脚本向F5VIP10.50.XX.67:8165提交POST请求时，运行一段时间后会卡住（即发送POST请求后无响应）,几秒后F5会返回RESET包。抓包杀手TCPDUMP：乍一看，很明显是F5发送了RESET包，很明显是F5的错。事实上，有时眼见为实。要通过现象找到问题的本质。发送RESET包的人没有错。话不多说，直接拿出大杀器tcpdump就行了，这种疑难杂症需要猛药才能攻克。在客户进行批量操作时，我们在以下三个位置抓包。1、在F5设备上执行tcpdump抓包#同时抓取客户端IP、F5VIP、服务器IP，可以抓取整个接入链路的数据包，方便定位故障点#抓取clientIP,F5VIP,serverIP同时抓取整个访问链路的数据包，方便定位故障点var/tmp/test0421-6.pcap.pcap2.XX信防火墙抓包，抓取流经上行接口feth11和下行接口feth10的所有流量。3、在服务器Server110.160.XX.81和Server210.160.XX.82上使用tcpdump抓取流经服务器网卡的所有数据包。抓包时：测试端使用脚本运行批处理时，三点同时抓包。当测试端再次失败时，三点停止抓包。数据包分析：不负众望，成功重现故障现象。接下来是最重要的阶段，数据包分析（pot）：1.F5上的数据包分析：testclient到F5VIP包分析（clientside）：注意故障包时间：20:57:12，下面的分析是基于这个时间点故障数据包的分析，注意数据包之前的时间！！！通过wireshark查看F5上tcpdump抓取的数据包，找到故障会话。可以看到客户端10.50.X.88:54373访问F5VIP10.50.XX.67:8165的访问流量。通过数据包，我们可以得到如下信息：Client10.50.X.88:54373访问F5VIP10.50。XX.67:8165已成功建立三次TCP握手。客户端发起POST请求，F5确认收到请求(ack)F5不响应给客户端的http响应。F5返回一个RST给客户端。RST的原因是：F5RST(peer)TCP重传超时（retransmissiontimeout）。实际上，F5和客户端建立TCP三次握手后，F5会根据负载算法选择一台服务器进行TCP三次握手建立链路，然后转发客户端发送的POST请求到真实服务器：在wireshark上使用F5加上扩展插件，在sessionflow中也可以看到如下信息。在此会话中，F5选择10.160.XX.82:8000。此服务器F5开启源地址转换功能，将客户端真实IP地址10.50.XX.88转换为10.50.XX.247。源端口为43166。2、F5数据包分析：F5（10.50.XX.247）到10.160.XX.82:8000流量分析（服务器端）：通过wireshark查看F5上tcpdump抓取的数据包，过滤tcp。port==43166，可以看到F5终端（10.50.XX.247:43166）访问server210.160.XX.82:8000的访问流量，通过数据包我们可以得到如下信息：当F5终端（10.50.82:8000）XX.247:43166)尝试与server2通信10.160.XX.82:8000建立链接F5向server2发送SYN包，但是server2没有响应SYN-ACKF5触发重传机制，3次重传后无响应服务端（所以F5触发RST机制，强行断开客户端）3、服务端数据包分析：server210.160.XX.82数据包分析：通过上面F5上的数据包，我们分析了clientside和serverside之间的数据交互，以及初步判断F5与服务器se建立链接失败rver2。假设可能的原因如下：防火墙将F5发给server2的SYN包转发给了Server2，Server2没有收到。防火墙将F5发给server2的SYN包转发给Server2，Server2收到但没有响应。防火墙没有收到F5发给服务器server2的SYN包，防火墙收到了F5发给服务器server2的SYN包，但是没有转发给服务器server2。现在让我们先解决假设2。这很容易。我们可以直接查看server2上抓取到的数据包，如果在20:57:12收到防火墙发来的数据包，说明防火墙已经转发了该数据包，server2是否在数据包中响应一目了然。通过数据包我们可以得到如下信息：server20.160.XX.82在20:57:03之后没有收到来自F510.50.XX.247:43166的任何数据包。4、拨云见日：XX信防火墙数据包分析：通过查看server2上的抓包，可以看出server2还没有收到F5发来的数据包，下一步就清楚多了，留下XX信firewall,checkXX通过抓包信件，基本可以解决剩下的三个假设，直接定位问题。接下来就是见证奇迹的时刻：打开XX信防火墙的数据包一看：通过数据包的比对，故障包定位在20:57:131415秒。SYN数据包发送到server2，但没有从feth10接口传出。...故障定位：通过以上分析，我们大概可以还原出整个故障原因：首先，客户端发起了一个批量操作。在不断的POST过程中，XX信中间的防火墙转发的数据异常，导致服务器无法接收转发给服务的F5设备。然后F5尝试重传数据包。当3次重传仍未成功建立连接时，F5执行RST动作，强制断开服务器的连接。F5RST机制1、由于F5的全代理架构，客户端到F5（clientside），F5到服务器（serverside）维护一个TCP/IP协议栈。得益于架构设计，可以实现客户端与F5运行http2，F5与服务端运行http1.1，前端运行https，后端运行http。因此，F5将对TCP/HTTP等协议进行RFC合规性验证，在特定报文结构或协议安全下触发RST动作，确保业务安全和设备稳定性。以下是RST的一些说明，详见链接：链接：https://support.f5.com/csp/article/K13223总结通过逐层抓包，一步步逼近问题的真相，并乐趣仍然存在。虽然最后不是自己F5设备的问题，但是可以第一时间帮助客户定位的问题，这其实就是我们作为服务商的价值所在，有坑就打电话补吧，还有填补;填写（表格，资料！最近忙于F5CVE，没时间输出。老手们不用着急，我已经申请了rancher商业版的测试，现在准备搭建demo环境，rancher联动F5、k8s集群的干货正在路上！
