Reassembling TCP PDU
Hi Experts,
I would like to seek your assistance in solving the performance issues for the traffic passing the F5 BigIP appliance.
Here is the background information:
Our LoadBalancing instances are configured with SNAT. Since recently the whole global network was migrated from legacy networking to SD-WAN. Because SD-WAN leverages overlay tunnels the MTU inside the tunnels is lower and the TCP MSS is dynamically adjusted (in our case it is 1358). So when the client initiates a TCP connection (in our case HTTP/HTTPS) to the LoadBalancer, the F5 appliance sees this side of the connection with MSS 1358. However, when the LoadBalancer initiates a connection to the server side (based in the same DC) the default MTU is there and the default TCP MSS equals to 1460. In my understanding such misalignment in MSS causes the F5 to perform virtual reassembling of TCP PDU before sending it from one side to another. I strongly believe it may cause memory/buffer issues especially when we talk about whole userbase becoming on a lower MSS side.
We have performed a number of tests with traffic captures on client and LoadBalancer side. It shows that LoadBalancer does reassemble the whole TCP PDU before sending to whichever side. It also sends numerous TCP ZERO Window Size toward server eventually withing the TCP session.
We also tried to reach the same APP/URL from the VDI environment hosted in DC and there is no performance issues. We expect that having equal MSS on both legs (client-side and server-side) doesn’t require virtual reassembling on the LB and, therefore, the packets are forwarded only with IP header and TCP port changes (reverse NAT).
So, may I kindly ask if someone had similar symptoms in your knowledgebase and if my understanding is correct? Would there be any option in LB configuration to copy the MSS dynamically from the client side to the SYN packet sent to the server side? Or what would be other recommendations?
Thank you in advance,
Oleksandr