Wireshark｜记一次批处理异常报错的故障排除

写在前面：

最近一保险客户火急火燎的找到我说：“涛哥，我们最近这段时间每天晚上在执行批处理的过程中，频繁的报错，十万次的HTTP POST请求中，大概会有六七百次的请求失败的情况发生，故障现象随时可以复现，赶紧帮看看“。经过老中医我一番悬丝诊脉，梳理完整个业务访问流程后，下一良方，辅以悍药猛攻，基本上药到病除。

由于此故障场景很有代表性，于是专门整理出这篇文章，希望能给到大家在日常运维排错中一点启发。话不多少，上干货。

网络逻辑拓扑及业务流：

业务的逻辑拓扑图，如下图所示。

批处理业务服务器：Server1 10.160.XX.81:8000、Server2 10.160.XX.82:8000。并且通过前端F5设备提供负载均衡和业务对外发布，VIP地址：10.50.XX.67:8165。

测试终端：通过Curl的方式向 F5 VIP 10.50.XX.67:8165 发送POST请求（批处理流程）

访问流程：

1. 用户使用脚本通过curl 提交POST请求到F5 VIP 10.50.XX.67:8165
2. F5将客户的POST请求按照负载均衡算法将请求转发给真实服务器Server1或者server2
3. F5和服务器之间有一个国产XX信的NGFW设备（上联F5设备使用的是防火墙feth11接口，下联交换机使用是防火墙feth10接口），注意防火墙出入接口，接下来分析数据包的时候会提到。

故障现象：

用户在使用脚本提交POST请求到F5 VIP 10.50.XX.67:8165的时候，运行一段时间后会卡住（即：POST请求发出后没有响应），几秒钟后收到F5 返回来的RESET包。

抓包大杀器TCPDUMP：

乍一看，很明显F5发了RESET包，显然是F5的锅嘛。其实有时眼见不一定为实，需要透过现象找到问题本质，并不是谁发了RESET包就是谁的锅。

话不多说，直接掏出大杀器tcpdump，这种疑难杂症还得猛药去攻。在客户执行批处理操作的同时，我们在以下三个位置进行抓包。

一、F5设备上执行tcpdump抓包

#同时抓取客户端IP、F5 VIP、服务器IP，可以抓全整个访问环节的数据包，方便定位故障点
tcpdump -ni 0.0:nnn -s0 host 10.50.xx.88 or 10.50.xx.67 or 10.160.xx.81 or 10.160.xx.82 -w /var/tmp/test0421-6.pcap.pcap

二、XX信防火墙抓包，抓取流经上联接口feth11和下联接口feth10的所有流量。

三、在服务器 Server1 10.160.XX.81、Server2 10.160.XX.82上使用tcpdump抓取流经服务器网卡的所有数据包。

抓包进行时：

测试端使用脚本跑批处理的时候，三个点同时进行抓包，当测试端故障复现，三个点停止抓包。

数据包分析：

不负众望，故障现象成功复现，下面进行最重要的阶段，数据包分（甩）析（锅）：

一、F5上数据包分析：测试客户端到F5 VIP数据包分析（clientside）：

注意故障包的时间：20点57分12秒，以下分析基于该时间点的故障数据包分析，注意数据包前时间！！！

通过wireshark查看F5上tcpdump抓取的数据包，找到故障会话，可以看到

客户端10.50.X.88:54373访问 F5 VIP 10.50.XX.67:8165的访问流量，通过数据包我们可以得到到以下信息：

1. 客户端10.50.X.88:54373访问 F5 VIP 10.50.XX.67:8165 TCP三次握手建立成功
2. 客户端发起了POST请求，并且F5确认收到该请求 （ack）
3. F5没有响应回http response给客户端
4. F5返回给客户端一个RST，RST原因为：F5RST(peer) TCP retransmit timeout（重传超时）。

事实上当F5和客户端建立完TCP三次握手之后，F5会基于负载算法选择一台服务器进行tcp三次握手建链，然后将客户端发来的POST请求转发给真实的服务器：

通过wireshark上使用F5的扩展插件，该会话流程中还能看到以下信息。

1. 在该会话中F5选择了10.160.XX.82:8000这台服务器
2. F5启用了源地址转换功能，将客户端的真实IP地址10.50.XX.88转换为10.50.XX.247
3. 源端口为43166

二、F5上数据包分析：F5 (10.50.XX.247)到10.160.XX.82:8000流量分析（serverside）：

通过wireshark查看F5上tcpdump抓取的数据包，过滤tcp.port ==43166，可以看到

F5端(10.50.XX.247:43166)访问 server2 10.160.XX.82:8000的访问流量，通过数据包我们可以得到到以下信息：

1. 当F5端(10.50.XX.247:43166)尝试与 server2 10.160.XX.82:8000建立链接
2. F5 发送SYN包给server2，但是server2并未无回应 SYN-ACK
3. F5触发重传机制，三次重传后未得到服务端的响应（于是F5 触发RST机制，强制断开客户端的链接）

三、服务器数据包分析：server2 10.160.XX.82 数据包分析：

通过上述F5上数据包我们分析了clientside和serverside的数据交互，得出初步结论，F5和服务端server2建立链接失败，假设可能的原因有以下几种：

1. 防火墙将F5给服务器server2发送的SYN包转发给了Server2，Server2没收到
2. 防火墙将F5给服务器server2发送的SYN包转发给了Server2，Server2收到但是没有响应
3. 防火墙没有收到F5给服务器server2发送的SYN包
4. 防火墙收到F5给服务器server2发送的SYN包，没有给服务器server2转发

现在我们首先解决假设2，这个很easy，我们直接查看在server2上抓的数据包即可，如果在时间点20点57分12秒收到了来自防火墙的数据包，那么代表防火墙转发了数据包，server2有没有回应zai数据包中一目了然。通过数据包我们可以得到到以下信息：

server2 0.160.XX.82在20点57分03秒后就再也没有收到来自F5 10.50.XX.247:43166的数据包。

四、拨云见日：XX信防火墙数据包分析：

通过查看server2上的抓包，我们看到server2并未收到来自F5的数据包，接下来就清晰多了，就剩下XX信防火墙了，查看XX信的抓包，我们基本上就可以解决剩下的三个假设，直接定位问题。

接下来就是见证奇迹的时刻：打开XX信防火墙的数据包瞅一瞅：

通过数据包对比查看定位到故障包时间点20点57分13 14 15秒钟XX信防火墙上联接口feth11收到了F5发给server2的SYN包，但是并未从feth10接口转出。。。。

故障定位：

通过以上分析，我们大概能够还原整个故障原因：

首先客户端发起批处理操作，在不断的POST的过程中，中间XX信防火墙转发数据异常，导致服务端无法接收到F5设备转发到服务端的数据，于是F5尝试重传数据包，当三次重传都未能成功建立连接后，F5执行RST动作，强制断开服务端的链接。

F5 RST机制

一、由于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设备的问题，但是能帮助客户第一时间定位问题，这其实也是我们作为服务商的价值，若有坑，召比填，填必满！最近一直再忙F5 CVE的事，一直没时间输出。老铁们不用担心，rancher商业版我这已经申请测试了，目前再搭demo环境，rancher联动F5和k8s集群的的干货文章在路上了！