Load balancing on cookie pattern NOT working

[sololuke2013]

Hi,

I try to configure ACE 4710 LB A5(2.1) LB to do following:

1. client send a http request for login to WEB srv

2. server response and send a cookie Set-Cookie with following pattern JSESSIONID=C333C37FCF083D210A639ABB8BB9DB21.S01 (33 random body 3 char string server ID)

3. Client send authorize http request to other server with the cookie in  URI (traffic not go via LB)

4. Authorize server send to WEB srv a request containing that cookie and wait for answer.

Client ----> ACE LB VIP ---> WEB server

Client -----> Authorize SRV ----> ACE LB VIP ----> WEB server

There are 4 WEB srv which have sessions ending in . S01 S02 S03 S04

I want that all login request to be round robin balanced, and authorize request to be forwarded to right WEB srv based on cookie termination S01 or .....

Configuration:

1. server farm probing

probe http http_8080

   port 8080

   interval 7

   passdetect interval 3

   passdetect count 4

   receive 2

   expect status 200 200

   open 3

2. cookie stickiness settings

sticky http-cookie JSESSIONID web-pro-srv-8080-stk

   cookie offset 33 length 3

   serverfarm WEB-pro-8080

   timeout 5

   replicate sticky

3. Traffic policy

class-map match-all WEB-pro-8080

   2 match virtual-address 192.168.123.100 tcp eq 8080

policy-map type loadbalance first-match WEB-pro-8080

   class class-default

     sticky-serverfarm web-pro-srv-8080-stk

policy-map multi-match EXTERNAL

  class WEB-pro-8080

     loadbalance vip inservice

     loadbalance policy WEB-pro-8080

     loadbalance vip icmp-reply active primary-inservice

Issue: Some sessions obtained at login are forwarded by LB      to wrong WEB srv

Can you please help me?

[rajsures]

Hi Luke,

I am not sure why "cookie offset 33 length 3" is required here. Again the offset value 33 and length value 3 is actually configured in bytes and not exactly based on number of characters in the cookie value. What happens if you remove the

"cookie offset 33 length 3" from the sticky configuration ? can you try removing this command and check if it works ?

Thanks,

Rajesh.

[sololuke2013]

Hi,

My 4 server pattern is like this JSESSIONID=C333C37FCF083D210A639ABB8BB9DB21.S01

or S02 or S03 or S04. 33 char + 3 char ServerID. As far as I know 1 char is 1 byte..... Anyway when I removed that or if I used lenght 10 and 3 for example it did not work. Conexion were round-robin.

[Kanwaljeet Singh]

Hi Luke,

By default if ACE cannot see that a user is already stuck to a server it will load balance that request normally which in your case could be round-robin(default) if you have not configured any specific LB method.

Now, in your case once the client sends a request and server sets the "Cookie" in response you should see an entry in "show sticky database". If the client comes back with same cookie, ACE should send the request to the same server.

You should see "show sticky database" output, also install "Live" HTTP utility in Mozilla or iehttp in IE and see if the client is coming with same cookie again? At the same  time show sticky database should show what cookie value ACE is looking for when client comes back. Other option is to take packet capture on ACE itself and see what client is coming with.

Your first requirement should be fulfilled since by default the LB method is round-robin. Once the client comes with a cookie and there is an entry already the connection is stuck to the same server. If it is not then there is a misbehave and pcaps as well as outputs above mentioned should help.

Regards,

Kanwal

[rajsures]

Hi Luke,

Lets say for your client request, server sent in response the following cookie "JSESSIONID=C333C37FCF083D210A639ABB8BB9DB21.S01". Ace will hash the cookie value "C333C37FCF083D210A639ABB8BB9DB21.S01" and associates the hash value with the real server in the sticky table entry. So when your Authorize SRV sends a login request to the ACE, if the cookie value is the same as

"C333C37FCF083D210A639ABB8BB9DB21.S01" then it will send the request to the same real server based on the sticky table entry.

You can check the sticky table using the following command to see what cookie value is associated with which real server:

show sticky database http-cookie "C333C37FCF083D210A639ABB8BB9DB21.S01"

To confirm if the "client" and "Authorize SRV" send the same cookie in their request you could take a packet capture on the ACE. If the cookie value is different then the ACE will check the sticky table and according to the match it will send to the correct real server.

Could you please confirm the cookie sent by both client and the Authorize SRV are same but still the ACE sends it to a different server ?

Thanks,

Rajesh.

[sololuke2013]

Hi all,

Thank you for help.

Issue solved using class map with cookie match on the fixed part .*S0x and a default "catch all" rules for traffic without cookie.

For failover I used backup on policy to move to other server farm.

I'm not using cookie stickiness anymore and all seems to work much better with that solution.