topic ACE30 stickiness issue in Application Networking

ACE30 stickiness issue

rjuchta — Wed, 23 Jan 2013 16:54:55 GMT

Hi,

we have a configuration as follows:

VIP/port1 -> rserver1/port11 | rserver2/port21

VIP/port2 -> rserver1/port12 | rserver2/port22

Users are connecting to an aplication via web browsers, some tags on the web page are available under VIP/port1, others tags - under VIP/port2

Round-robin works as predictor, for the stickiness "ip source address" is used.

The problem is that all connections initially directed to rserver1 in the end are redirected to rserver2, although rserver1 is always inservice (probes are ok) and stickiness time is long enough.

What can cause such a behaviour of ACE ?

Can it be because of some rserver1 malfunctions? And if so how ACE can say that rserver1 is not working properly?

Thanks

ACE30 stickiness issue

Borys Berlog — Fri, 25 Jan 2013 09:04:43 GMT

Hello Ryszard

I suspect that you just have 2 different sticky groups , so they are not tied to each other.

Could you please post a related part of config ?

ACE30 stickiness issue

rjuchta — Fri, 25 Jan 2013 14:23:35 GMT

Hi Borys,

yes, there have to be two different sticky groups:

one for rserver1/port11 | rserver2/port21 (serverfarm1) -> VIP/port1

and

one rserver1/port12 | rserver2/port22 (serverfarm2) -> VIP/port2

sticky ip-netmask 255.255.255.255 address source sticky-serverfarm1

timeout 60

serverfarm serverfarm1

sticky ip-netmask 255.255.255.255 address source sticky-serverfarm2

timeout 60

serverfarm serverfarm2

ACE30 stickiness issue

ajayku2 — Mon, 28 Jan 2013 08:02:51 GMT

Hi Ryszard,

You can configure the same sticky group in multiple policies or virtual servers. In that case, the sticky behavior applies to all connections to any of those policies or class maps. These connections are referred to as buddy connections.

because, if you configure both policy or class map 1 and 2 with the same sticky group, a client stuck to server A through policy or class map 1 will also be stuck to the same server A through policy or class map 2.

That will make sure that all the connection from the unique client goes to same server.

regards,

Ajay Kumar

ACE30 stickiness issue

rjuchta — Mon, 28 Jan 2013 19:03:03 GMT

Hi Ajay,

thanks for the hint, but it seems that this is not an issue. It appeared that when we turn off ("no inservice") rserver2 then the application is not working stable (for example some pages are not displayed in full). Still when we connect directly to rserver1 everything is just fine.

So it is something wrong with ACE->rserver1 connections and ACE is somehow aware of it, so all connections are redirected to rserver2 despite stickiness. But how to find out what is wrong? Maybe some tcp settings on rserver1 should be changed ?

ACE30 stickiness issue

ajayku2 — Mon, 28 Jan 2013 21:28:11 GMT

Hi,

Time to compare both servers:

Check if rserver1 is having dual nic. Make sure that the return traffic is not going back through other port.

The port towards ACE should be configured with gateway pointing to ACE IP address. ( If it is routed mode without snat)

Check if there is a difference in MTU between the two servers.

Ideally Packet capture will display who is the culprit.

Also when you do the testing make sure to clear the browser data, cookie, offline files etc.

Check if probe is failing for rserver1.

regards,

Ajay Kumar

ACE30 stickiness issue

rjuchta — Tue, 29 Jan 2013 21:03:24 GMT

Hi Ajay,

tcp setting (incl. mtu) are the same, interface and routing configuration also ... probes are always successful ...

Next week I'll be able to do some packet capturing to compare what is the difference when connecting directly rserver1 and when connecting via ACE.

Thanks

ACE30 stickiness issue

rjuchta — Wed, 13 Feb 2013 09:58:27 GMT

Hi,

after the rserver1 reloading content switch is now working ok.

But still I'm wondering how ACE is verifying server responses (html header, content, ... ?) so rebalances traffic to the other server despite stickiness settings ...

Does anybody know what exactly ACE is checking by default before balancing decision (with "no normalization" on interfaces) ? Or in what conditions html rebalance may occur ?