Forum Discussion
kgaigl
Cirrocumulus
CirrocumulusVirtual Service for Proxy Server: timeouts when traffic goes through LTM
Hi,
we've got since a few years our proxy Server (McAfee Webgateway, now SkyHigh) behind LTM.
We had originally 2 Members, later 4 Members, every Member had about 5000 tcp Connections, no problems.
Since about 2 Weeks we've very often Timeouts on Internet-Access (taking up to 20 sec to connect), but the Connections were not very increasing.
As a Workaround the most of the Clients are now directly connected to different new virtual Proxy-Instances without LTM. These Clients does not suffer on Timeouts, only the Clients who connect to Internet via LTM-> Proxyserver.
None of the Statistics on LTM show high CPU or Memory Usage.
The LTM are VM's on ESXI, BIG IP Version 16.1.4.2
We use VS-Type Standard, no SSL-Interception, only a modified http Profile with "Insert XFF enabled"
We are very much focused on Problems of the Proxy-Server, but since the Workarounds show, that Internetacess without LTM is much more reliable without LTM, I'm asking where I could try to tune the LTM-side.
Any Ideas?
Thank You
- Jeffrey_Granier
Employee
What client/server-side TCP profile are you using? are any of the timeout settings tuned? Are you leveraging window scaling in your profiles?
kgaiglHi Jeffrey,
we use the default tcp profile (serverside: client-profile), nothing tuned
- kgaigl
another thing: if we have only one Member in the Pool, there are no Timeouts, if I enable a second, then Timeouts appear
ShripatyCirrus
Is there any kind of session being maintained
- Jeffrey_Granier
so if you add the 2nd pool member in and the timeouts appear then likely the 2nd pool member has some type of issue. Do you have pcaps of traffic going to 2nd pool when a timeout occurs?
I also recommend using tcp_wan_optimized for client side and tcp_lan_optimized for server side tcp profiles. The default profiles may not have window scaling enabled. Additionally the tcp progressive profile Overview of the f5-tcp-progressive profile may be of interest but start with the other two first. Traffic should be better optimized with those in place
- kgaigl
Hi Jeffrey,
sorry, was a little bit unexact:
it makes no difference which one of the Pool Member I activate. If I activate a second Pool Member AND some Load (roundabout 3000 Connections per Pool Member), then Timeouts appear.
But first I changed the tcp Profiles according to your advice
- kgaigl
i've tried your suggestions:
with lan/wan optimized it was not better, but with progressive it looks better, I'll watch for a while.
what I see under statistics: a lot of packets (about the 50 %) are "Segment out of Order"
thank you
- Jeffrey_Granier
I would keep an eye on the ltm logs whne timeouts have occured, what type of big-ip is this? HW ? - model , SW? Using snat? if so perhaps you need to add a snatpool and additional IP's if you reach snat exhaustion this can generate timeouts.
- kgaigl
these are VM's with Version 16.1.4.2 and we use snat pool. We've already increased snat-pool from 3 to 5 adresses
- kgaigl
I see in the Log a lot of messages:
tmm[11047] http_process_state_prepend - Invalid action:0x107030 serverside (192.168.15.212:8080 -> 192.168.15.101:54880) clientside (192.168.249.103:54880 -> 192.168.15.200:8080) (Server side: vip=/Common/vs_proxy profile=http pool=/Common/POOLproxy server_ip=192.168.15.212)
- Jeffrey_Granier
This looks to be related to non-compliant HTTP messages see our KB article - Error Message: http_process_state_prepend - Invalid action (f5.com)
OneConnect profile could also play a role if this is not HTTP compliant traffic. You should reach out to support to look at this further
