10-25-2013 11:04 AM
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?
10-28-2013 04:51 AM
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.
10-28-2013 08:59 AM
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.
10-28-2013 10:26 AM
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
10-29-2013 06:05 AM
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.
11-01-2013 09:37 AM
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.
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: