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,
Hi @O_Muz ,
What I have got from your environment , you have some issues with Fragmentation resulted from variance in MTUs Values in Client side peers , Also " TCP Zero Window " sometimes indicates there is a peer sends traffic with a rate higher than the oppsite peer.
So maybe adjusting MTU value from F5 Loadbalancer or SD-WAN tunnels " to make their MTUs Value identical " should solve this issue.
> in Case you are using SNAT listners , you can adjust MTU value for external Vlan , I mean the Vlan which " SNAT Listner " operates or listnes to client traffic , such as below :
- Try to adjust it to match with your MSS/MTU SD-WAN tunnel value , and check again.
If you use the Full proxy architecture with Virtual servers as a listeners , Check below :
> I recommend to create a custom TCP profile for the Client side and adjust the MSS value as below snap shot:
and attach this Profile in " Protocol Profile (client) " in your targeted virtual server which serves your application , and do not forget to assign another TCP profile in " protocol Profile (server) ".
I hope my reply helps you