10-02-2002 06:44 PM
Hello,
We recently purchased an old Arrowpoint CS-150, and upgraded WebNS to 4.01. Our setup isn't very complicated; we're only loading balancing traffic between two webservers at the moment. For testing purposes, we have one web server serving a very simple page, and the other one serving a complex page with lots of graphics, flash and frames. The problem is that the complex page refuses to load properly. Every time it's loaded, there will be graphics missing or a frame will be missing its page, etc. It's not a web server issue because the page displays fine when viewed without the Arrowpoint in between. What causes this problem, and how can we resolve it? Any help is appreciated, thanks in advance.
-A.Hsu
Solved! Go to Solution.
10-04-2002 05:53 AM
Andy,
The port number in the service tells the CSS what port to send the client request on to the backend server. In essence it will do a port nat on the backend when you specify the port in the service. In many cases the content rule and and service have a port specified, but quite honestly you do not need to specify the port in the service unless the request coming into the CSS is different then what you want to send the webserver.
With that said, if all the requests going to the webservers need to be on port 80, then simply specify that port in each service. Then in the content rule specify the port that is coming in from the client.
When you begin to change port numbers in services, make sure you also use the appropriate "keepalive port" on that service so that you do not allow a service to be 'active' when it really isn't. For example, using the default icp keepalive on a service that is trully listening on port 81 where the webserver is actually having tcp port 81 issues could fake the CSS out thinking that the service is up and keep trying to send requests to the backend server.
Regards
Pete..
10-03-2002 02:44 AM
Check that you have enabled some sort of stickyness. ex "advanced-balance sticky-srcip"
If you are using "balance roundrobin" (and some others) the individual requests for page objects will hit different servers, and if the content on the servers is not replicated, you will get a page where something is missing.
10-03-2002 04:27 AM
LEt me add here that persistence may be causing you some problems as well which may be causing what the previous responder was talking about. If a persistant connection is coming in, you may have multiple requests coming in a being load balanced to either server.
In the content rule I would configure "no persistent"
In the global section of the config I would configure "persistence reset remap"
Give that a shot,
Pete Knoops
Cisco Systems
10-07-2002 07:03 AM
Can you explain what the 'persistence reset remap' command does? The command reference doesn't give any detail about what back-end remapping actually does.
Thanks,
Terry
10-07-2002 10:36 AM
Terry,
The "persistence reset remap " command will perform a backend remapping operation when resetting a connection. This is only done on the backend and not seen on the client side.
Pete..
10-03-2002 01:54 PM
Thanks a lot for the help, I implemented the suggestions from the both of you, and it took care of the problem right away.
I do have another question though. I would also like to be able to go to a specific server by entering a different port number in the URL or IP address. The way I was able to get this to work was by creating a new service with the new port number for each server, and then creating a new content rule with the corresponding port number for each server. I then had to make the web server listen on the specified port number.
Ideally though, we would like to have this functionality without any modifications to the web server configuration since this wouldn't tell us anything in the event of a port 80 problem. I tried adding the existing port 80 service to a new content rule that reacted to port 81, but this didn't seem to work. Is there another way of going about this?
Thanks again for all the help,
A.Hsu
10-04-2002 05:53 AM
Andy,
The port number in the service tells the CSS what port to send the client request on to the backend server. In essence it will do a port nat on the backend when you specify the port in the service. In many cases the content rule and and service have a port specified, but quite honestly you do not need to specify the port in the service unless the request coming into the CSS is different then what you want to send the webserver.
With that said, if all the requests going to the webservers need to be on port 80, then simply specify that port in each service. Then in the content rule specify the port that is coming in from the client.
When you begin to change port numbers in services, make sure you also use the appropriate "keepalive port" on that service so that you do not allow a service to be 'active' when it really isn't. For example, using the default icp keepalive on a service that is trully listening on port 81 where the webserver is actually having tcp port 81 issues could fake the CSS out thinking that the service is up and keep trying to send requests to the backend server.
Regards
Pete..
10-04-2002 12:27 PM
Thanks Pete, that did the trick.
--Andy
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: