topic Re: Sticky 11501 problem. in Application Networking

Sticky 11501 problem.

ahmadfarkhan — Thu, 23 Feb 2006 09:28:26 GMT

Dear Champions,

owner TAHAN

content WEB

vip address 202.71.106.111

add service WEB1

add service WEB2

add service WEB3

protocol tcp

advanced-balance sticky-srcip

sticky-inact-timeout 60

flow-reset-reject

active

I have some problem here which is some users can access and some users cannot access to the Webserver using https (SSL). The users cannot access is not totally cannot access. For example morning session user A can login and do transaction but on afternoon session user A cannot access and have to wait for a couple of time before can access to webserver again. Is there any fine tunnig did i need to change for the configuration above ?. What is the best sticky-inact timeout time ?

Re: Sticky 11501 problem.

Gilles Dufour — Thu, 23 Feb 2006 16:58:31 GMT

you should capture a sniffer trace to verify what is going on.

I feel like one of your server is having problems, so with your example, user A would connect to web1 and have no problem, and with your sticky timeout, user A will keep using web1 until the sticky entry timeout.

So, when connection again in the afternoon, user A is sent to web2 which is having a problem and the connection fail.

But for the time of sticky-timeout, A will be sent to web2 and the connections will fail.

So, capture a trace and verify your servers.

Your config is fine. No tunring required.

Gilles.

Re: Sticky 11501 problem.

ahmadfarkhan — Fri, 24 Feb 2006 02:08:32 GMT

Hi giles,

Thanks for your reply. Is there any solution or config change to make sure load balancer will not send to web2 which is having problem?. What i mean is load balancer can define which server is dead and alive.

Re: Sticky 11501 problem.

Gregory Scarlett — Fri, 24 Feb 2006 10:07:26 GMT

The CSS will be sending pings to the servers by default. If it receives a response, it will mark the server as alive. If the webserver software is having problems, the CSS will still be keeping it up if it responds to a ping.

You can change the keepalive to HTTP, which will give a better indication. Have a look at this URL for more details:

http://www.cisco.com/en/US/partner/products/hw/contnetw/ps792/products_configuration_guide_chapter09186a0080576069.html#wp1098267

As Giles suggested, a packet capture would show exactly where the problem is, but the keepalives will help if it is the server that is the problem.

Hope this helps.

Greg.