【MVS】关于F5 Virtual-Server回应TCP RST ACK报文的问题分析

客户端（内网地址）————NAT设备（公网地址）————（公网地址）F5负载均衡————（内网地址）服务器

客户端通过针对F5设备对应业务虚服务的8080端口进行探测，发现概率性存在端口check fail故障现象存在。

经过抓包对比分析发现，正常业务探测的报文在收到TCP RST报文后是不会再收到TCP RST ACK报文。

客户端连接显示check fail的主要原因是在收到TCP RST报文后又收到了相同端口的TCP RST ACK报文。

由于客户端发出的报文在公网出口做了SNAT，源地址和源端口发生变化，但是IP报文的标识没有变化，根据两个TCP RST ACK报文的标识分别为ip.id == 58526和ip.id == 19482，在F5侧进行抓包可以此标识进行过滤和跟踪对应的异常流。

通过对F5侧抓包进行分析发现，F5侧收到的报文相对客户端发出的报文有存在缺失（Tcp Previous Segment Not captured）和乱序（Tcp Out-Of-Order）现象，说明中间通信链路不稳定。同时F5发出的TCP RST ACK报文提示为[f5rst: no flow found for ack],这是因为在先前的连接中业务侧已经发出RST报文重置连接，对应的F5设备上的connection表项已经释放，此时如果因为客户发包异常（第一条流客户收到TCP RST之后又发送TCP ACK报文）或者报文乱序导致F5侧再收到相同端口同时携带ACK标识的TCP报文，由于F5是全代理架构需要检查TCP连接状态，由于先前对应端口的connection表项已释放，此次F5侧会直接回应报文TCP RST ACK给到客户端。

从上面的分析可以知道，F5侧发送TCP RST ACK报文机制并无异常，主要原因是中间网络波动导致的报文丢失和乱序问题以及客户端发包机制异常问题。

由于这种异常情况主要发生在业务端口短连接测试的TCP连接断开场景中，在实际业务运行的长连接场景下故障现象可能不会有感知，建议现场进一步测试观察。