ACE static cookie
I leverage "cookie insert broswer-expire" to use ACE generated static cookie.
Now I add some additional "static cookie-value "xxx" rserver xxx", in order to make cookie more "meanful" and would be easier for troubleshooting.
But how can I activate the new static cookie, since the previous static cookit never expires? thanks.
If I understand you question correctly then
you would like to configure cookie string value when using the COOKIE insert feature.
This was possible in CSS using string command.
With ACE currently you cannot configure a cookie-value for the cookie that is inserted by ACE (-- using cookie-insert feature). ACE
always automatically add a cookie value for the cookie it inserts.
This cookie value is similar to R2482639152
If you use
static cookie-value "xxx" rserver yyy"
The static cookie option will only work if a client happens to come in with
the cookie=xxx. Then that connection will be stuck to rserver yyy.
Syed
Similar Messages
-
ACE : Stickyness with static cookies problem
Hi Gilles
I restart a conversatoion as a question to clarify the situation :
I followed your recommendation to configure static cookie entries in each sticky group, but I still experience the problem of sessions getting re-load balanced to the second server when returning from HTTPS to HTTP :
It seems that the ACE ignores the static entries !
To make my question clear, I repeat hereafter the setup and the encountered problem :
Here is the setup :
An ACE load balance user requests on two Apache servers
cookie-insert is used to stick a user on one Apache server
The home page is accessed via http on port 80
On the Home page, there is a link to allowing the user to login
The login process uses SSL
During the login, backend SSL is required between the ACE and the selected Apache server
The login is a POST request to the Apache server
After a successful login, the home page is reloaded on port 80 and the name of the user should appear on the top of the page
The ACE configuration :
Two sticky groups are configured : one for HTTP acess and another for HTTPS access
Two server farms are defined, both using the same real servers, but with different ports (80 and 443)
In the ECOM_STICKY_TEST_HTTP stick group the two following cookies are automatically generated :
R105816849 for the server HQCHECOM01
R105852786 for the server HQCHECOM02
In the ECOM_STICKY_TEST_HTTPS stick group the two following cookies are automatically generated :
R355972695 for the server HQCHECOM01
R357158616 for the server HQCHECOM02
I statically configured in the each sticky group the cookies used by the other sticky group, to allow stickiness when the browser switches from HTTP to HTTPS and vice versa :
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTP
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTP backup WEB_REDIRECT_001
56 static cookie-value "R355972695" rserver HQCHECOM01
64 static cookie-value "R357158616" rserver HQCHECOM02
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTPS
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTPS backup WEB_REDIRECT_001
72 static cookie-value "R105816849" rserver HQCHECOM01
80 static cookie-value "R105852786" rserver HQCHECOM02
serverfarm host ECOM_FARM_TEST_HTTP
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 80
inservice
rserver HQCHECOM02 80
inservice
serverfarm host ECOM_FARM_TEST_HTTPS
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 443
inservice
rserver HQCHECOM02 443
inservice
The problem :
Let analyse the sequence of events and the value of the http cookie for each of them :
When the the home page is originally loaded, the ACE selects SERVER-1
The ACE inserts the cookie "A" in the server responses
The user is sticked to SERVER-1
Then, the user tries to login and an SSL session is established with the ACE
The user sends a POST request containing the cookie "A"
A backend SSL session is established with SERVER-1
The POST request is forwarded to SERVER-1
SERVER-1 responds with a 200 OK and the ACE generates another cookie "B" as it belongs to the sticky group ECOM_STICKY_TEST_HTTPS
The client browser reloads the page on port 80 and provides the cookie "B" (the last received)
The ACE sees the cookie "B" and should use the static cookie entry to select the SERVER-1
But instead, the ACE perform another load balancing decision and selects SERVER-2 !
The page is reloaded, but the name of the user does not appear on it
LiveHTTP Trace on Firefox :
GET /ecom/medias/sys_master/8800775602206/Home-page-main-banners-video.jpg HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105816849;
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105816849; path=/
Date: Mon, 18 Oct 2010 15:31:37 GMT
Server: Apache/2.2.13 (Red Hat)
Connection: close
Transfer-Encoding: chunked
Content-Type: image/jpeg
Here we switch on HTTPS :
https://ecom.test.toto.com/uk/en/j_spring_security_check
POST /uk/en/j_spring_security_check HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105816849; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
Content-Type: application/x-www-form-urlencoded
Content-Length: 75
spring-security-redirect=&j_username=yves144%40yahoo.com&j_password=junon01
Here we see cookie for the same server but for the HTTPS sticky group :
HTTP/1.1 302 Moved Temporarily
Set-Cookie: STICKED-TO=R355972695; path=/
Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
Date: Mon, 18 Oct 2010 15:31:39 GMT
Server: Apache/2.2.13 (Red Hat)
Location: http://ecom.test.toto.com/uk/en/home
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8
Here we switch back to HTTP :
http://ecom.test.toto.com/uk/en/home
GET /uk/en/home HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R355972695; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
Here we see that the second server has been wrongly selected !
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105852786; path=/
Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
Set-Cookie: JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2; Path=/; HttpOnly
Date: Mon, 18 Oct 2010 15:31:40 GMT
Server: Apache/2.2.13 (Red Hat)
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Language: en-GB
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8
http://ecom.test.toto.com/ecom/medias/sys_master/8796174057502/uk.gif
GET /ecom/medias/sys_master/8796174057502/uk.gif HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105852786; JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2;
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105852786; path=/
Date: Mon, 18 Oct 2010 15:31:40 GMT
Server: Apache/2.2.13 (Red Hat)
Content-Length: 382
Connection: close
Content-Type: image/gif
Hypothesis :
It seems that the static entries are not considered by the ACE...Yves,
you have to specify the destination port
56 static cookie-value "R355972695" rserver HQCHECOM01 80
64 static cookie-value "R357158616" rserver HQCHECOM02 80
serverfarm host ECOM_FARM_TEST_HTTP
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 80
inservice
rserver HQCHECOM02 80
inservice
Gilles. -
Hello,
I have a following configuration:
sticky http-cookie STICKY_TMP STICKY_TMP
cookie insert ...
Cookies are sent and stickiness works. Everything is ok... Almost :-)
Now I have a question regarding value of cookies created by ACE.
Currently cookies have values that look like this "R4224709512"
Is it possible to change this value so it reflects the target node that processes requests for this sticky session. This cookie could contain i.e. ip address of real server.
Arrowpoint cookie on CSS1150 worked this way...
Another question. How do I identify this cookie value with sticky-entries in "show sticky database static" output?
This command doesn't show anything like R4224709512, but only numbers like 18293255029648678255
best regards
KubaI am using ACE with version A3(2.1).
The “sticky-entry” in "show sticky data static"is a hash of the cookie-value set by ACE for the real server. so you need to use "show sticky database http-cookie " to determine which server are serving the client.
ACE-1/routed(config-pmap-lb-c)# do show sticky database http-cookie
sticky group : web-sticky
type : HTTP-COOKIE
timeout : 5 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
---------------------+----------------------+--------------+-------+
16820511103801384579 lnx1:0 0 -
sticky group : web-sticky
type : HTTP-COOKIE
timeout : 5 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
---------------------+----------------------+--------------+-------+
3347854103021350619 lnx2:0 0 -
..sometimes they'd only show up w/ the static instead of the cookies option for some reason.
found some explanation about this:
http://docwiki.cisco.com/wiki/Session_Persistence_Using_Cookie_Learning_on_the_Cisco_Application_Control_Engine_Configuration_Example
There is a difference between inserting an ACE-generated cookie or using one learned by the ACE. The cookie-insert feature creates a static cookie.
To look at static cookies you need to use the command:
show sticky database static
if you try static cookie (cookie inserted by ACE), the value is placed in the static sticky table at the time of configuration...
so no need to send traffic, once the static sticky config is in place, you should see an entry with 'show sticky database static'.
Do not try to filter the table with some other parameters...they do not work until A2(1.4)
There are 2 database:
One for static entries and one for dynamic entries.
Every show command that does not include the static keyword will look into the dynamic database.
So, you won't see anything by using those commands.
You could perform some test to identify which cookie is sent to which server.
The cookie value is static, so the number of value is limited to the number of servers.
There is a dynamic cookie learning feature available in ACE.
Kinly tell me if you want to discuus about that.
Kindly rate if possible.
Kind regards,
Sachin garg -
Can anybody telle me the purpose of the number (56) in the following statement:
56 static cookie-value "R355972695" rserver HQCHECOM01Hi Regent,
It does seem to be the line number but it increase by 8 for every entry. Couldn't find anything else for that number.
switch/Admin(config-sticky-cookie)# do sh running-config sticky test
Generating configuration....
sticky http-cookie jsessionid test
8 static cookie-value "R1" rserver r1
16 static cookie-value "R2" rserver r2
24 static cookie-value "R3" rserver r3
32 static cookie-value "R4" rserver r4
40 static cookie-value "R5" rserver r5
48 static cookie-value "R6" rserver r6
56 static cookie-value "R7" rserver r7
Regards,
Kanwal -
ACE: Stickyness, Cookie in URL
Hello,
I have a problem with cookies in the URL if the browser does not support Cookies in the http header.
I'm setting the cookie in the url static , so the URL looks like:
http://testfarm/sticky.cgi?serverid=1.1.1.1
And configure the sticky group:
sticky http-cookie serverid sticky-farm cookie secondary serverid
replicate sticky
serverfarm sticky-farmm 8 static cookie-value "1.1.1.1" rserver server1
16 static cookie-value "1.1.1.2" rserver server2
What's wrong with my configuration?
If the client accepts cookies in the Cookie header anything works but not if the client rejects the cookie.Hi Gilles,
no, i did not specify a port in the serverfarm or in the realserver.
The configuration looks like this:
sticky http-cookie serverid ST-sticky-farm
cookie secondary serverid
replicate sticky
serverfarm sticky-farm
8 static cookie-value "1.1.1.1" rserver server1
16 static cookie-value "1.1.1.2" rserver server2
policy-map type loadbalance first-match L7-10-1-1-1
class class-default
sticky-serverfarm sticky-farm
policy-map multi-match L4_SLB_POL_external
description L4 Policy fuer SLB ohne NAT
class V-10-1-1-1
loadbalance vip inservice
loadbalance policy L7-10-1-1-1
loadbalance vip icmp-reply active
appl-parameter http advanced-options HTTP-rebalance
class-map match-any V-10-1-1-1
2 match virtual-address 10.1.1.1 tcp eq www
serverfarm host sticky-farm
probe tcp80-i30
rserver server1
inservice
rserver server2
inservice
rserver host server1
ip address 1.1.1.1
inservice
rserver host server2
ip address 1.1.1.2
inservice
Sven -
Hello Everyone,
i have a ACE 4400 Appliance, for balance some applications on the network.
i have one application(citrix), the connection to this site is https(443).
I had a balance of cookie, plus this only worked if I left only one server in "inservice" on Serverfarm if I add the second, the application showed me a scree saying "your web interface session is in an inconsistent state."
Since the above problems, I set the cookie for connection to work with "persistence rebalance," but the problem continued.
After I passed the Serverfarm to be balanced by source IP, the troubles are over, I kept the persistence rebalance.
Now comes the question, why not work with cookie? https does not work if the balancing change something in the package, such as information inside a cookie?
Old configuration:
sticky http-cookie NFUSE-COOKIE STICKY-HIAE-NFUSE-COOKIE
cookie insert browser-expire
replicate sticky
serverfarm SF-HIAE-NFUSE
Current Configuration:
sticky ip-netmask 255.255.255.255 address source STICKY-HIAE-TESTE-NFUSE
replicate sticky
serverfarm SF-HIAE-NFUSE
Class/Policy and Parameter map.
class-map match-all VS-HIAE-NFUSE
2 match virtual-address 192.168.16.30 tcp any
policy-map type loadbalance first-match VS-HIAE-NFUSE-l7slb
class class-default
sticky-serverfarm STICKY-HIAE-TESTE-NFUSE
class VS-HIAE-NFUSE
loadbalance vip inservice
loadbalance policy VS-HIAE-NFUSE-l7slb
loadbalance vip icmp-reply active primary-inservice
appl-parameter http advanced-options HTTP-OPTS
parameter-map type http HTTP-OPTS
persistence-rebalance
Tks a lot.
Rafael MendesRealized the configuration as specified in the link.
Apparently, everything ok.
However, I can not access the page using internet explorer. I tested with firefox, safari, opera, everything works with internet explorer not.
Configuration follows below, is something wrong?
Thanks.
serverfarm host SF-HIAE-NFUSE
description Servidores nfuse.einstein.br
rserver WPVAP06
inservice
rserver WPVAP07
inservice
parameter-map type generic sslidparam
set max-parse-length 70
sticky layer4-payload STICK-L4-NFUSE-SSL
serverfarm SF-HIAE-TESTESSLTERM
response sticky
layer4-payload offset 43 length 32 begin-pattern "\x20"
class-map match-all VS-L4-NFUSE-SSL-TERMINATOR
2 match virtual-address 192.168.16.254 tcp eq https
policy-map type loadbalance generic first-match VS-HIAE-TESTESSLTERM
class class-default
sticky-serverfarm STICK-L4-NFUSE-SSL
policy-map multi-match int10
class VS-L4-NFUSE-SSL-TERMINATOR
loadbalance vip inservice
loadbalance policy VS-HIAE-TESTESSLTERM
loadbalance vip icmp-reply active primary-inservice
appl-parameter generic advanced-options sslidparam -
ACE Module Cookie Parsing causes Reset Connection
I am trying to upgrade my ACE Modules from A2(1.3) to A2(3.2) . Unfortunately, the cookie parsing breaks when there are illegal characters and causes a connection reset (RST) when there is an invalid cookie, but only on code later than A2(1.3).
The cookie in question is being passed by a third party so making them change the cookie is not necessarily do-able. The cookie has the following value:
Cookie: CurrentUser={"UserKey":{"Key":"anonymous"},"LastUpdated":"10/13/2010 1:35:52 PM"}
We are using the following parameter map:
parameter-map type http CASE_PARAM
case-insensitive
persistence-rebalance
set header-maxparse-length 20480
length-exceed continue
On the older code, the request is passed on to the server.
Is there a setting similar to "length-exceed continue" that I can give the ACE to tell it to ignore cookies it cannot parse?HTTP inspection is not enabled.
Did you mean adding a class-default to the policy-map?
Adding it to the policy-map does make it match the class-default. Unfortunately, cookie parse errors result in the inability to parse both the cookie and the host header as well. It seems that rather than just failing to parse the cookie and being unable to do sticky matching - it completely fails the entire header parsing.
Here's our setup:
rserver host test1
ip address 192.168.1.101
inservice
rserver host test2
ip address 192.168.1.102
inservice
rserver host test3
ip address 192.168.1.103
inservice
rserver host test4
ip address 192.168.1.104
inservice
serverfarm host auto
probe HTTP-diagnostic
rserver test1
inservice
rserver test2
inservice
serverfarm host news
probe HTTP-diagnostic
rserver test3
inservice
rserver test4
inservice
sticky http-cookie autoCookie auto-cookie
cookie insert browser-expire
replicate sticky
serverfarm auto
sticky http-cookie newsCookie news-cookie
cookie insert browser-expire
replicate sticky
serverfarm news
class-map type http loadbalance match-any auto
2 match http header Host header-value "www.auto.local"
3 match http header Host header-value "auto.local"
class-map type http loadbalance match-any news
2 match http header Host header-value "www.news.local"
3 match http header Host header-value "news.local"
class-map match-all prod_VIP
2 match virtual-address XXX.XXX.XXX.XXX tcp eq www
policy-map type loadbalance first-match prod_POLICY
class auto
sticky-serverfarm auto-cookie
class news
sticky-serverfarm news-cookie
class class-default
sticky-serverfarm auto-cookie
policy-map multi-match aggregate-slb-apps
class prod_VIP
loadbalance vip inservice
loadbalance policy prod_POLICY
loadbalance vip icmp-reply active
loadbalance vip advertise
appl-parameter http advanced-options CASE_PARAM -
I just implemented ACE 4710, A3(2.4) in our network. It is doing loadbalancing with ssl termination. I configured stickiness using server cookies. My client is telling me cookie is sent in clear text on the Inernet. Is there a way on ACE to encrypt it?
your help is greately appreciated.This is just not possible.
The cookie is part of the http header and the complete http data (header + content) is encrypted in the same SSL connection.
So not possible.
Have your customer send you the sniffer trace showing the problem.
Gilles. -
Hi,
I'm trying to configure a cookie-based slb method which corresponds to my current CSS11503-configuration. Basicly, my CSS performs slb purely based on the content of the arrowpoint-cookie, using the following config:
advanced-balance arrowpoint-cookie
arrowpoint-cookie name WPS6
The cookie contains the real ip of the underlying webserver and the CSS fowards traffic based on that particular content of the cookie. Whenever we need to do an unscheduled shutdown of a webserver, we gracefully take the webserver out of service by setting the weight to 0, but also, my webdepartment have implemented a feature in Websphere, that somehow sends a cookie-expire to both the SESSIONID-cookie and the WPS6 cookie. So once the subsequent http-req hits the CSS, the cookie is gone and the CSS lb'es the req to a diffent server. We've intentionally left out the sticky-option, as it didn't work well with the before mentioned Websphere-feature.
Now I'm trying to configure something similar on the ACE, but so far without luck. I did start by configuring sticky-group with the cookie-insert option and a http-parametermap with persistence-rebalance. But all attempts to recreate the above mentioned scenario, have failed. It's seems, that even with persistence-rebalance, the client-session is still stuck to the webserver and a display of the sticky-database shows, that the sticky-entry persists. Even when I manually delete the cookie-container on the client and verify with the Live-HTTP-plugin, that the subsequent http-req does not contain the WPS6 cookie, the req is still forwarded to the realserver. Even when the real-server is placed in 'inservice standby'.
Is it possible to staticly define a cookie-value for, say, 4 webservers, each with their own unique cookie? And when the initial part of the tcp is completed and the ACE decides which realserver is to be used, it sets a cookie containing that particular value and includes it in the http-response. So if any subsequent http-req's are not containing that cookie, the ACE re-balancences that req and sends it to a different webserver.
/Ulrich
PS! Merry X-masUlrich,
what you're asking for is what ACE does currently.
The static cookies are created at configuration time.
You can see the values with "show sticky cookie-insert"
ie:
switch/Admin# show sticky cookie-insert group portalap
Cookie | HashKey | rserver-instance
------------+----------------------+----------------------------------------+
R4181073320 | 11105909834649097754 | vmware-http/vmware-27:80
R4181109257 | 10017312105356339124 | vmware-http/vmware-28:80
R4183409225 | 15537882249682767338 | vmware-http/vmware-46:80
R4183517036 | 1787657754489574767 | vmware-http/vmware-49:80
Whenever we see the cookie "R...." we check if the associated server is alive and forward the connection to that server.
Otherwise we loadbalance to a new server and include the new cookie in the response.
For established connections, persistence rebalance is indeed required to inspect every request and rebalance the connection to a new server if a new cookie is detected. However ACE will try not to rebalance when not needed.
If you need a new loadbalancing decision each time, you need 'persistence rebalance strict'.
An alternative could be the configuration of 'failaction purge' to force the connection to be terminated when the server goes down.
'inservice standby' is described @ http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1000333
•Tears down existing non-TCP connections to the server
•Allows current TCP connections to complete
•Allows new sticky connections for existing server connections that match entries in the sticky database
•Load balances all new connections (other than the matching sticky connections mentioned above) to the other servers in the server farm
•Eventually takes the server out of service
As you can see, this option still allows connection to the server if it matches a sticky entry.
Gilles. -
ACE : Stickyness problem with http cookies
Hi,
I am facing a serious problem with stickyness in a e-commerce configuration.
Here is the setup :
An ACE load balance user requests on two Apache servers
cookie-insert is used to stick a user on one Apache server
The home page is accessed via http on port 80
On the Home page, there is a link to allowing the user to login
The login process uses SSL
During the login, backend SSL is required between the ACE and the selected Apache server
The login is a POST request to the Apache server
After a successful login, the home page is reloaded on port 80 and the name of the user should appear on the top of the page
The ACE configuration :
Two sticky groups are configured : one for HTTP acess and another for HTTPS access
Two server farms are defined, both using the same real servers, but with different ports (80 and 441)
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTP
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTP
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTPS
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTPS
serverfarm host ECOM_FARM_TEST_HTTP
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 80
inservice
rserver HQCHECOM02 80
inservice
serverfarm host ECOM_FARM_TEST_HTTPS
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 443
inservice
rserver HQCHECOM02 443
inservice
The problem :
Let analyse the sequence of events and the value of the http cookie for each of them :
When the the home page is originally loaded, the ACE selects SERVER-1
The ACE inserts the cookie "A" in the server responses
The user is sticked to SERVER-1
Then, the user tries to login and an SSL session is established with the ACE
The user sends a POST request containing the cookie "A"
A backend SSL session is established with SERVER-1
The POST request is forwarded to SERVER-1
SERVER-1 responds with a 200 OK and the ACE generates another cookie "B" as it belongs to the sticky group ECOM_STICKY_TEST_HTTPS
The client browser reloads the page on port 80 and provides the cookie "B" (the last received) !!
The ACE sees the cookie "B" but does not find it in its database for the sticky group ECOM_STICKY_TEST_HTTP
The ACE perform another load balancing decision and selects SERVER-2 ! (instead of SERVER-1)
The page is reloaded, but the name of the user does not appear on it
The question :
As it is not possible to have only one sticky group in this configuration what would be the solution to make sure that the same server is selected for http and https ?
Thank you for any hints,
YvesHi Gilles,
I followed your recommendation to configure static cookie entries in each sticky group, but I still experience the problem of sessions getting re-load balanced to the second server when returning from HTTPS to HTTP :
It seems that the ACE ignores the static entries !
To make my question clear, I repeat hereafter the setup and the encountered problem :
Here is the setup :
An ACE load balance user requests on two Apache servers
cookie-insert is used to stick a user on one Apache server
The home page is accessed via http on port 80
On the Home page, there is a link to allowing the user to login
The login process uses SSL
During the login, backend SSL is required between the ACE and the selected Apache server
The login is a POST request to the Apache server
After a successful login, the home page is reloaded on port 80 and the name of the user should appear on the top of the page
The ACE configuration :
Two sticky groups are configured : one for HTTP acess and another for HTTPS access
Two server farms are defined, both using the same real servers, but with different ports (80 and 443)
In the ECOM_STICKY_TEST_HTTP stick group the two following cookies are automatically generated :
R105816849 for the server HQCHECOM01
R105852786 for the server HQCHECOM02
In the ECOM_STICKY_TEST_HTTPS stick group the two following cookies are automatically generated :
R355972695 for the server HQCHECOM01
R357158616 for the server HQCHECOM02
I statically configured in the each sticky group the cookies used by the other sticky group, to allow stickiness when the browser switches from HTTP to HTTPS and vice versa :
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTP
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTP backup WEB_REDIRECT_001
56 static cookie-value "R355972695" rserver HQCHECOM01
64 static cookie-value "R357158616" rserver HQCHECOM02
sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTPS
cookie insert browser-expire
timeout 240
replicate sticky
serverfarm ECOM_FARM_TEST_HTTPS backup WEB_REDIRECT_001
72 static cookie-value "R105816849" rserver HQCHECOM01
80 static cookie-value "R105852786" rserver HQCHECOM02
serverfarm host ECOM_FARM_TEST_HTTP
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 80
inservice
rserver HQCHECOM02 80
inservice
serverfarm host ECOM_FARM_TEST_HTTPS
description *** e-Commerce Test Server Farm ***
probe ECOM_PROBE_TEST
rserver HQCHECOM01 443
inservice
rserver HQCHECOM02 443
inservice
The problem :
Let analyse the sequence of events and the value of the http cookie for each of them :
When the the home page is originally loaded, the ACE selects SERVER-1
The ACE inserts the cookie "A" in the server responses
The user is sticked to SERVER-1
Then, the user tries to login and an SSL session is established with the ACE
The user sends a POST request containing the cookie "A"
A backend SSL session is established with SERVER-1
The POST request is forwarded to SERVER-1
SERVER-1 responds with a 200 OK and the ACE generates another cookie "B" as it belongs to the sticky group ECOM_STICKY_TEST_HTTPS
The client browser reloads the page on port 80 and provides the cookie "B" (the last received)
The ACE sees the cookie "B" and should use the static cookie entry to select the SERVER-1
But instead, the ACE perform another load balancing decision and selects SERVER-2 !
The page is reloaded, but the name of the user does not appear on it
LiveHTTP Trace on Firefox :
GET /ecom/medias/sys_master/8800775602206/Home-page-main-banners-video.jpg HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105816849;
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105816849; path=/
Date: Mon, 18 Oct 2010 15:31:37 GMT
Server: Apache/2.2.13 (Red Hat)
Connection: close
Transfer-Encoding: chunked
Content-Type: image/jpeg
Here we switch on HTTPS :
https://ecom.test.toto.com/uk/en/j_spring_security_check
POST /uk/en/j_spring_security_check HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105816849; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
Content-Type: application/x-www-form-urlencoded
Content-Length: 75
spring-security-redirect=&j_username=yves144%40yahoo.com&j_password=junon01
Here we see cookie for the same server but for the HTTPS sticky group :
HTTP/1.1 302 Moved Temporarily
Set-Cookie: STICKED-TO=R355972695; path=/
Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
Date: Mon, 18 Oct 2010 15:31:39 GMT
Server: Apache/2.2.13 (Red Hat)
Location: http://ecom.test.toto.com/uk/en/home
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8
Here we switch back to HTTP :
http://ecom.test.toto.com/uk/en/home
GET /uk/en/home HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R355972695; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
Here we see that the second server has been wrongly selected !
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105852786; path=/
Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
Set-Cookie: JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2; Path=/; HttpOnly
Date: Mon, 18 Oct 2010 15:31:40 GMT
Server: Apache/2.2.13 (Red Hat)
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Language: en-GB
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8
http://ecom.test.toto.com/ecom/medias/sys_master/8796174057502/uk.gif
GET /ecom/medias/sys_master/8796174057502/uk.gif HTTP/1.1
Host: ecom.test.toto.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ecom.test.toto.com/uk/en/home
Cookie: STICKED-TO=R105852786; JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2;
HTTP/1.1 200 OK
Set-Cookie: STICKED-TO=R105852786; path=/
Date: Mon, 18 Oct 2010 15:31:40 GMT
Server: Apache/2.2.13 (Red Hat)
Content-Length: 382
Connection: close
Content-Type: image/gif
Hypothesis :
It seems that the static entries are not considered by the ACE... -
Shouldn't ACE 4710 ignore cookie stickiness when the server is down?
Hello,
I have implemented sticky load balancing with cookies. The problem is that if one of my two servers in the server farm is down (and even if the ace recognizes it as down via a probe) it keeps sending the requests to the server that is down, obviously because it has set a cookie for this server,
Shouldn't the ACE ignore the cookie when the server is down?
Is there a command to ignore cookie stickiness if the server is down? Is there another workaround?
an example of my config is
serverfarm host SF_Ebanking
rserver RS_IAS_1 XXXX
conn-limit max 4000000 min 4000000
probe http_probe_ebanking
inservice
rserver RS_IAS_2 XXXX
conn-limit max 4000000 min 4000000
probe http_probe_ebanking
inservice
sticky http-cookie ACE_COOKIE ebanking_sticky
cookie insert
replicate sticky
serverfarm SF_Ebanking
16 static cookie-value "server01" rserver RS_IAS_1
24 static cookie-value "server02" rserver RS_IAS_2
thanks,
georgeThis is not as obvious as you seem to believe.
ACE will not select a server that is down !!!! Even if the cookie points to that server.
What might be happening is that the connection from the browser to the ACE has not been killed, so when client sends a new request it reuses the existing connection and ACE does allow an existing connection to be maintain with a dead server by default.
Try the command 'failaction purge' under the serverfarm.
This should kill the active connections with the dead server and allow a new connection to be open with the other server even if the cookie points to the dead one.
Regards,
Gilles. -
Configuring cookie based sticky on ACE
I have an ACE and I am trying to setup stickiness based on HTTP cookies. My objective is to stick a client to one of the real servers in the server farm until the the cookie expires. I am using the same COOKIE name for all three servers but using different values that are unique to each server. On testing I discovered that each client request when stuck to the same real server always uses the same sticky database entry and a browser refresh updates the same entry...what am I doing wrong?
My config is as follows:
context Admin
member STICKY
access-list ALL line 8 extended permit ip any any
rserver host SERVER1
description content server 1
ip address 134.178.51.17
inservice
rserver host SERVER2
description content server 2
ip address 134.178.51.18
inservice
rserver host SERVER3
description content server 3
ip address 134.178.51.19
inservice
serverfarm host SFARM1
predictor leastconns
rserver SERVER1
inservice
rserver SERVER2
inservice
rserver SERVER3
inservice
sticky http-cookie MYCOOKIE STICKYGroup
timeout 4
serverfarm SFARM1
class-map type http loadbalance match-any L7CLASS6
2 match http cookie MYCOOKIE cookie-value "123456"
3 match http cookie MYCOOKIE cookie-value "56789"
policy-map type loadbalance first-match L7POLICY6
class L7CLASS6
sticky-serverfarm STICKYGroup
class class-default
serverfarm SFARM1
class-map match-all V1L4VIPCLASS
2 match virtual-address 134.178.51.10 tcp eq www
policy-map multi-match V1L4SLBPOLICY
class V1L4VIPCLASS
loadbalance vip inservice
loadbalance policy L7POLICY6Cookie values are learned dynamically by ACE and sticky entries are created.So you do not need to match cookie values.
With Sticky group configuration you tell ACE which Cookie-name to look for in the HTTP traffic passing through ACE.
So following should be sufficient
sticky http-cookie MYCOOKIE STICKYGroup
timeout 4
serverfarm SFARM1
policy-map type loadbalance first-match L7POLICY6
class class-default
sticky-serverfarm STICKYGroup
Lets assume your Server1 is setting cookie value 123456 by using "SET-Cookie:MYCOOKIE=123456" & Server2 is sending ""SET-Cookie:MYCOOKIE=56789" the flow will be as follows
1. If a new client hits the VIP on ACE with no cookie set then ACE will select a Sever from the server farm as per the LB algo and forward the HTTP request to the selected server. Lets suppose ACE selects Server1.
3. Server1 will send "SET-Cookie:MYCOOKIE=123456" in the HTTP response to the client.
4. ACE on getting this response from Server1 will dynamically learn that Server1 is setting up cookie value 123456 and will create a sticky entry in the database.
(Due to this sticky db entry any subsequent http requests with "Cookie:MYCOOKIE=123456" will be directly forwarded to Server1.
5. This sticky entry in ACE sticky DB will only time out if "timeout in minutes" configured under sticky group elapses and no active conns are using this entry.With every new http request matching the sticky entry this timeout is initialized.
6. If a new client come with no cookie set in the Http request then ACE will select a server using LB logic and will learn the cookie value & will create appropriate sticky entry.
7. If a client sends a request with cookie value present then ACE will simply look into the sticky db and forward the request to the appropriate server.
HTH
Syed Iftekhar Ahmed -
Hi, I am trying to understand the ACE`s cookie-insert method of stickiness. So the ACE will always insert a cookie into the http-header when sending a response to the client/browser. Based on that if it recieves the same cookie-id in the subsequent requests it knows to which end-server to send it as it does an internal hash based on the cookie-value.
My question is, what happens if the server also sends a cookie? Does ACE dis-regards that cookie and inserts a new one on it`s own? How do the cookie-insertion from the server (which is done by default by the web-servers) co-exist with the cookie insertion by the ACE?
thnxHi,
As long as they don't both use the Same Cookie name they won't influence each other.
If you don't assign a cookie-name ACE will create a unique one per rserver.
Or you can configure one e.g.
rserver WebServer1 80
cookie-string "ACEWS1Cookie"
More details can be found here:
http://www.cisco.com/en/US/customer/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/sticky.html -
I'm looking for some guidance/thoughts on a problem I'm coming across. I have an SSL termination configuration as follows:
Client to VIP:80 does redirect to VIP:443
Client to VIP:8080 does redirect to VIP:8443
Client to VIP:443 load balances to Real:80
Client to VIP:8443 load balances to Real:8080
On the real server I'm running apache on 80 and tomcat on 8080.
Apache handles the main site while Tomcat handles java applets/authentication/etc.
The problem we're encountering is when apache needs to hand off to tomcat and the reverse. What's the best way to accomplish this while maintaining the connection to the same real server. What is happening is that the ACE is re-load balancing the request to a different real.
Thanks.you could use static cookies [ cookie insert ].
Since you have 2 serverfarms, you'll get 2 different set of cookies.
So, for each sticky group, you need to learn the cookie value associated with each rserver.
Then for the other group, configure a static entry for each cookie value.
Do the same for each group.
Learning the cookie value requires the use of a sniffer. Sniff traffic going to the ACE slot. Open a connection to the vip and see which server is being used and what cookie value is returned. Delete the cookie and repeat until you get the cookie value for each server.
This is the only idea I have right now.
Gilles. -
Hi,
I have an http session between Web Server farm and Application Server Farm.
After firt http request, Application Server send this pck (see file http_header.txt ).
So, I configured http cookie Stickiness with Dynamic cookie learning:
sticky http-cookie JSESSIONID Cookie-Bea-Group
cookie offset 0 length 64
timeout 70
timeout activeconns
replicate sticky
serverfarm BEA8-SFARM-3
But it doesn't work. But if web server received an answer from Application server with only one set-cookie
Set-Cookie:JSESSIONID=xxxxx
It work
if in the http header there are two set-cookie doesn't work.
I need stick the session based only on JSESSIONID cookie.
Is it possible and how?
Thanks
DinoHi Dear,
The ACE appliance/module has the dynamic cookie feature.
You then just need configure the cookie name and the box does the rest.
When static cookies are used there will only be one entry in the cookie database per real server. So, if ace-cookie is the only cookie defined and there are two servers, there will only be two entries in the sticky database, even if there are thousands of user sessions.
Dynamic cookie learning is another option for keeping the SAP session persistent. The sticky table can hold a maximum of four million dynamic entries (four million simultaneous users). The key is choosing the right cookie name.
Lets take an example of SAP sets a number of cookies for various purposes (note the ace_cookie was set by Cisco ACE using cookie insert, not SAP), but the saplb_* cookie is set by SAP specifically for load-balancers. It has the format saplb_=()[].
Here, the cookie value also helps to verify which server instance and physical node you are connected to.
The configuration process for cookie learning is similar-with a few changes in the syntax.
Example configuration:
ssticky http-cookie saplb_* ep-cookie
replicate sticky
serverfarm EP-HTTP
policy-map type loadbalance http first-match ep-policy
class class-default
sticky-serverfarm ep-cookie
In the above examples, the replicate sticky command is used so that the cookie information is replicated to the standby Cisco ACE context. With this implementation, session persistence is maintained in the event of a failover. The default timeout is one day.
The show sticky data command retrieves the active sticky entries that have been dynamically learned. The value shown is not the actual cookie value, but a function of it created by Cisco ACE.
Example configuration:
switch/SAP-Datacenter# show sticky data
sticky group : ep-cookie
type : HTTP-COOKIE
timeout : 100 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
---------------------+--------------------------------+--------------+-------+
6026630525409626373 SAP-EP:50000 5983
Load Balancing Identifier
The Load Balancing Identifier used for Load balancing to Web AS Java instances has the following syntax.
saplb_=()[]
The cookie is set on path=â/â and domain=.
The same syntax applies if the identifier is used via url rewriting.
The applies only to the J2EE Engine where session stickyness on a process (JVM) level is required. The uniquely identifies a set of instances. If there are no special group definitions then the special group identifier '*' is used. This will be the case for a default installation.
The SAP Web Dispatcher checks for path prefix match and thereby determines group name. This allows to obtain from the set of dispatch cookies or to do initial load balancing for the group. The Java dispatcher receives the request and also checks for the group. The Java dispatcher then reads from the appropriate dispatch cookie or performs initial dispatch on his local nodes.
The CSS does not have the possibility to learn dynamic cookie value created on the server.
So, you can either use arrowpoint cookies which is quite simple or have your server team add a static value to the jsessionid in order to identify the server.
We can then configure the CSS to locate this static value and match it to a service.
If possible kindly rate.
Keep in touch.
Kind regards,
Sachin Garg
Maybe you are looking for
-
Help please with Palm Address and Memo Files
Hello.. I am new to this board, but perhaps someone can help me. I have a PalmOne Zire 31 and have used it for years. Primarily I used the Desktop verision on my laptop. Well, my laptop died and was recently replaced. Fortunately, as it was on it
-
Can't find photo stream on iPhoto
When I first had my iphone in September 2012, my photos were downloaded directly to my macbook through icloud. Now, I can't seem to see the photos I took on my phone on my computer. Does anyone know why it would stop working? Do I need to update i
-
Hello, I've developed a new problem. everytime, after another user uses my Dual quad G4 1.25, the color profiles are messed up. Not only does the profile switch, but it is not possible to change it back. I just get a error sound when I select other p
-
Ok so i keep getting this annoying msg "we cannot connect you to blackberry app world. please ensure that your device is connected to thei wireless network and try again." but i have found only 2 temp fixes either take out the battery to restart bb s
-
i need to open a session in first servlet and use its values in the second one... but i cant find really useful sample and .... i did it this way: ////////////////////in first servlet////////////////////////////////// HttpSession session = req.getSes