Forum Discussion
RonVDigipolis
Altostratus
AltostratusConnection loss Client -> F5 BIGIP LTM
Hi all,
I am currently experiencing an issue with an application that is being used on 3 application servers (windows server 2003), loadbalanced behind the F5 BIGIP.
Users are sometimes losing connection to the server, which makes the application crash.
I have launched a capture for one of these clients and I'm seeing the following when this issue occurs (capture.png):
Client: 10.229.237.235, IP of virtual server on BIGIP: 172.20.5.41
From what I can see there is no SYN-ACK being returned from BIGIP.
There are also a lot of messages in the log containing TCP Window Full & TCP out of order.
When we let the user connect directly to an application server instead of passing through BIGIP, they have no issues. The capture is also very clean in that case, no retransmissions, no duplicate acks or TCP resets..
The TCP protocol being used is Protocol Profile (Client) - TCP LAN Optimized and for Protocol Profile (Server) - TCP WAN Optimized.
Does anyone have an idea why BIGIP doesn't send a SYN-ACK in this case?
I was thinking maybe an issue with receiving window & send buffers.. Or would I need a capture on the virtual server to further analyze this behaviour?
Any help would be greatly appreciated!
Thank you
Kind regards
Ron
NAGCirrostratus
Hi
1)
Assuming that the 3 application servers (windows server 2003), which are behind the F5 BIGIP are in the same Physical location as of F5, Protocol Profile (Server) should be LAN optimised and not WAN optimised.
Depending on where Clients are, you should use appropriate Protocol Profile (Client) profile.
2)
Depending on how much load BigIPs currently are under, if you filter for packets of specific client experiencing issue, it will be safe.
You can use following command::
tcpdump -vvni 0.0:nnnp -s0 host <client_IP> -w /var/tmp/file_name.pcap
This will capture packets on both client and server side
Hope it Helps,
Nag
- F5SJ_
Altocumulus
If this capture is from pool members to vip then it could be related to buffer size, changing buffer size could solve the problem.
RonVDigipolisAlso, launching a capture on the virtual server is kind of a problem because we can't reproduce the issue.. And from what I'm hearing a capture could create heavy load..
- RonVDigipolis
Sry, it was the other way around:
Protocol profile (client): tcp-wan-optimized
protocol profile (server) tcp-lan-optimized
I will try the capture filtered on client IP, thank you for the suggestion :)!
Kind regards
Ron
- RonVDigipolis
Issues are most likely linked to windows server 2003 using TCP window of 64240. We were going to try to use windows scaling, but developers have decided to migrate the application to windows server 2012 (which uses auto sizing of the TCP window). So hopefully this will resolve the issue 🙏
shamjeeNimbostratus
Current I'm seeing the similar issue, any idea what was the fix for this case?