ACE30 stickiness issue

[rjuchta]

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

[Borys Berlog]

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 ?

[rjuchta]

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

[ajayku2]

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

[rjuchta]

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 ?

[ajayku2]

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

[rjuchta]

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

[rjuchta]

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 ?