Product Guides
Proxy CSS1500 issue
I have an issue with load-balancing connections from a proxy server.
The issue is some of the services I am running on the backend server farm require persistance. This is posing a problem as with source IP persistance - the connections will all always go to the same real server as the connection are all being sourced by the proxy server.
I have thought about cookie persistance, but think the same issue will occur as the cookie will be placed on the proxy and not the real client intiating the request.
I have also thought of using L4 persistance but once again we will hit the same issue as the same port will alway be coming from the proxy server.
Has anyone come across this issue before and know how to resolve it? Any help would be greatly appreciated.
Expert's answerTo see where changes need to be made, we need to look at each step in the communications process. Starting with the CS1500, I would make sure you are running the latest version of firmware available for the device. If this doesn't resolve the problem, try opening a case with Cisco TAC to see if there are any configuration changes that you can make that will help resolve the problem. I will assume that you are using a commercial proxy server for the rest of the options that I will discuss. While Cisco TAC may push back a bit because you are using a third-party proxy server, they should still be able to provide some troubleshooting steps to help you identify where the problem is and possibly how to resolve it. Try to white list the internal servers that you are having problems with. Whitelisting in the context I have used it will tell the proxy server not to do anything in terms of caching the server or anything else. If this appears to fix things, then you need to start digging deeper into the proxy server configuration to see how you can get things to work the way you need them to. As with the CSS1500, I would suggest that you installe the lastest firmware/software for the proxy server. This could either fix the problem or give you some additional tools to work with. The next troubleshooting step is to run a proctocol analyzer at three different points - between the CSS1500 and the external part of your network where the users are, between the proxy server and the CSS1500 and between the servers and the proxy server. Sniffing the traffic between each of these points should give you additional information as to where configuration changes to consider. It will also provide the vendor technical support folks you will be working with good information to help identify a fix. When looking for a fix for a problem when the traffic is flowing between a load balancer and a proxy server, document the steps you took to find the information about how the communications are flowing. I worked with one of my readers last year who was in a similar configuration and found that with one of the applications on their network that each time the application was upgraded that they had to make minor tweaks to the previous fix to get things to work again. Having the initial resolution documented helped to quickly identify what had to be changed to get things working again. |
Buy a BIG-IP... simple...
Buy a BIG-IP... simple...
Understand the proxy.
The original question had this statement-
"I have thought about cookie persistance, but think the same issue will occur as the cookie will be placed on the proxy and not the real client intiating the request."
I don't know what proxy is in use but it has been my experience that proxies such as Squid or AOL's proxy that are designed to service desktop web browsers do not store cookies and simply pass them back to the original requester. If the proxy is a WAP proxy that services phones it is quite common for the proxy to manage cookies on behalf of the requester but in that case cookies are usually stored for each client and are handled transparently to the application.
This is a round about way of saying that I believe the cookie load balancing approach should work. I would recommend trying it and see what happens. We used cookie based persistence for load balancing on a pair of CSS11050 switches with requests coming through a WAP proxy and it worked just fine.
You were on the right track...
If you have a situation where all traffic comes through a proxy and hence the same source IP address, in your content rule use the advance-balance arrowpoint-cookie. What this does is inject it's own cookie between the load-balancer and the server in the farm to track the sessions and maintain persistance. Then balance on leastconnections.
Config Snippet:
content rule1
vip address 192.168.16.100
balance leastconn
advanced-balance arrowpoint-cookie
add service www01
add service www02
add service www03
redundant-index 100
active
Post new comment