Forum Discussion
NimbostratusLoad Balancing Web Proxy Servers
I have three WebMarshal Web Proxy Servers
1 VIP
VIP service port is 8080
Performance L4 rule (I need to do this as I need the VIP to not respond to the port if all pool members are down)
Pool has the three servers on 8080
SNAT Auto Map
Source Address Affinity
Simple, right? Well, when users are accessing HTTPS sites via the LTM to the Proxy servers I get complaints of slowness, timeouts, disconnects. I'm not offloading SSL, I'm using this VIP as more of a pass through to the proxy servers.
Am I missing something very obvious? Right now I had to flip the proxy alias back to the old CSS until I can get this stable for the users as it was breaking sites that were required for them to perform their job functions.
Any guidance I can get from this community would be much appreciated.
Thanks!
6 Replies
Michael_YatesHi agvelegol,
Since you are load balancing Web Proxy Servers I wonder if you are going for too aggressive of a profile setup. The Layer 4 Performance Profiles are associated with a FastL4 Protocol Profile (Client). These have aggressive timeout values (TCP Close Timeout 5 seconds) for high speed "fast in / fast out / close" instead of the default TCP Profile which is geared for a more persistent client interaction (TCP Timeout 5 minutes).
Your clients connections could be getting closed too fast, causing the need for a new connection to be opened which would translate to sluggish performance.
I would suggest changing to a "Standard" Type with a normal / default Protocol Profile (Client) of "tcp" and see if the performance improves. If you need to increase the timeout values you can create a custom TCP Profile and up the Idle Timeout values as needed.
For your concerns "Performance L4 rule (I need to do this as I need the VIP to not respond to the port if all pool members are down)" you can control several behaviors.
On the Pool, set the Action On Service Down to "Reselect". If a server fails, all clients will be re-load balanced to a different server in the pool. The default is "None" which would result in a hard failure and the user would have to manually restart the session and be re-load balanced.
For the "all pool members are down", you can create an iRule using the active_members command to sense the availability of the pool members and take whatever action you like if none are available (redirect, alternate pool of proxy servers, etc.).
Hope this helps.
comunicaciones_Hi all.
Our case is close to the one described by agvelegol, but our VS is a standad one.
We have placed one BIG-IP to balance the HTTP/HTTPS traffic between our workers and two HTTP/HTTPS SQUID proxies. The VS has no profile applied but one HTTP profile to pass the x-forwarded-for, and a Persistence Profile to ensure that the same client source address is served by the same proxy server due to a existent Kerberos dialog between client and proxy server for which the BIG-IP should be transparent.
The problem is that when a client try to connect to an HTTPS site:
- the CONNECT macro reaches the VS
- the VS forwards it to the chosen proxy server
- the proxy server asks back for authentication
- the F5 forwards back this authentication to the client
- in that moment the F5 launchs a RST packet to the server and to the client.
This behaviour is repeated several times until the connection is down.
This behaviour doesn't happen with HTTP traffic, and the authentication that the proxy asks to the client through the F5 is successful.
Are we missing some configuration in the VS? Must it be configured as an Explicit HTTP proxy applying the http-explicit profile? Must it be configured on the contrary, with an http-transparent profile?
I would appreciate any help. Thanks a lot.
- nitass
Employee
Are we missing some configuration in the VS? Must it be configured as an Explicit HTTP proxy applying the http-explicit profile? Must it be configured on the contrary, with an http-transparent profile?
if you use http profile, i understand you have to disable the profile when getting connect method. also, layer 7 persistence profile may not work when the profile is disabled.
when HTTP_REQUEST { if { [HTTP::method] eq "CONNECT" } { HTTP::disable } }anyway, since you are load balancing web proxy, http-transparent profile may be a better choice.
- comunicaciones_
Hi, nitass:
Thank you for the comment. We did some improvements in the past days. We have discover that this behaviour is a bug in our present BIG-IP version, 11.5.1, and it is corrected in the 11.5.2. Until we do the upgrade, we are going to apply exactly the bypass you mention in your post, that is also the temporal solution that F5 recommends officialy. In our case, the F5 is not doing really the role of a transparent proxy, but a role of load balancing between two servers (two proxy servers in this case), so we don't see clearly if applying an http-transparent profile could be good in our case. Thank you once again for your help.
- nitass
we don't see clearly if applying an http-transparent profile could be good in our case.
i understand it does forward invalid http packet instead of dropping. anyway, it is okay if http profile works fine in your case.
The Transparent Proxy Mode enables the BIG-IP system to forward invalid HTTP traffic to a specified server, instead of dropping the connection. By configuring an HTTP profile to forward invalid HTTP traffic, you can manage various atypical service provider scenarios, such as HTTP traffic from non-browser clients that function as web browsers.
Manual Chapter: HTTP Profiles (Proxy mode)
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-0/7.html - comunicaciones_
Hi, nitass: Up till now, we have not seen problems in our environment that could indicate packets dropping by the balancer, so we don't think that is our case. Anyway, we will have in mind your useful comments if it happens in the future. Thanks a lot.
