Http cookie stickiness

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
Dino

Hi 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

Similar Messages

  • ACE 4710 Can not confirm http cookie sticky connections

    We are using a ACE 4710 with A3(2.6) software release.
    I had to change our sticky load balancing method for HTTPS to cookie based.
    However while connections appear to work if I look at the sho sticky database table I can not see or confirm sticky entries for the cookie based connections.
    Here or config snippets to show the config
    sticky http-cookie ghh-www scook-ghh
      cookie insert browser-expire
      serverfarm ghh-www-443
    class-map match-all ghh-www-443_CLASS
      2 match virtual-address 172.16.1.21 tcp eq https
    class-map type http loadbalance match-any ghh-www-443_CLASSURL
      2 match http url [.]*
    policy-map type loadbalance first-match ghh-sticky-443_POLICY
      class class-default
        sticky-serverfarm scook-ghh
    policy-map multi-match POLICY
    class ghh-www-443_CLASS
          loadbalance vip inservice
          loadbalance policy ghh-sticky-443_POLICY
          loadbalance vip icmp-reply active
          appl-parameter http advanced-options CASE_PARAM

    Another point: please check whether your servers are listening only for HTTPS traffic or also for HTTP traffic:
    in the first case the ACE will have to: decrypt the traffic from the client, inspect the http header to take the loadbalance decision and then re-encrypt it and send it to the server
    in the second case the ACE would have to: decrypt the traffic from the client, inspect the http header to take the loadbalance decision and send it out as it is unencrypted to the server
    the second solution would have the benefit of being easier to configure and to require less resoucerces both on the ACE (only decryption to be performed) and on the servers (no need for SSL operations at all there) but it might be that your company or business sector have requirements for which this traffic should never flow unencrypted, in which case you would have to go for the first solution.
    Here you have a config example for the first solution:
    http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c6f37.shtml
    I would not expect you to have to pay extra for importing the cert and kepair into the ace, it would be just a copy, however as Alex said that may still depend on the license agreement with the CA.
    Cheers,
    Francesco

  • ACE with sticky http-cookies across two server farms issue

    Hi,
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:"Times New Roman","serif";}
    We need the same sticky http cookie to applied to two server farms (which are actually the same servers but listening on different ports in each farm) to persist sessions to the same real backend server.
    e.g.
    Farm1 (front end HTTP service) - StickyGroup1
    rserver1 - 192.168.0.1:80
    rserver2 - 192.168.0.2:80
    rserver3 - 192.168.0.3:80
    Farm2 (SSL front end authentication service) - StickyGroup2
    rserver1 - 192.168.0.1:443
    rserver2 - 192.168.0.2:443
    rserver3 - 192.168.0.3:443
    We have setup two Sticky Groups (one for each of the farms above) both using the same cookie name e.g. cookieXYZ
    Our service is behind a single virtual server configured as follows (example URL and addresses):
    Virtual Server Configuration
    Virtual server name: www.somedomain.com
    Virtual IP: 2.2.2.2
    TCP/443 (https)
    SSL Termination - Proxy service name: www.somedomain.com (all keys and certs loaded and correct)
    L7 Load Balancing - **inline** rule match HTTP URL:(/AuthenticateMe/).*  Action : Sticky, Group: StickyGroup2, SSL Initiation enabled (www.somedomain.com)
    Default L7 Load Balancing action : Sticky, Group: StickyGroup1
    So normally we would expect users to first hit www.somedomain.com first and therefore Farm1, get cookieXYZ from the ACE (cookie insert is only enabled on StickyGroup1) and then be redirected to www.somedomain.com/AuthenticateMe which matches the inline URL L7 rule which directs the request at Farm2 - at this point we expected the ACE to use cookieXYZ to persist the user to the same real server hit in Farm1 but instead the stickiness doesn't seem to work.
    We suspect that the ACE uses IP:port as the unique value in the Cookie ID and therefore the ACE fails to match the same real host in a different farm because we are using a mix of port numbers across farms. Is this correct? Is there another way of accomplishing what we are after with a different configuration but still the same setup with single VIP and multiple services on the backend servers?
    Any suggestions or solutions appreciated.
    Thanks
    Paul

    The issue is related to the fact that it's not about persistence because there are only "new" services in the backend in SSL, you want to keep the IP address.
    With a little bit of dev, the only way to acheive this is to redirect the user when he has been sent to http and adding a "tag" (cookie / token in the URL), then on the SSL virtual server, when performing SSL offload matching this tag to send to user to the right server. But it will be a 1-to-1 mapping.

  • Sticky Resource Not Available when setting up sticky http-cookie

    When I try to configure the sticky:
    (config)# sticky http-cookie ACE-COOKIE COOKIE-STICKY
    I get the error:
    sticky resource not available
    An L7 policy has not yet been set up… could that be the reason for this error? Or, is it because I have not setup a class resource for the sticky cookie?

    Syed,
    I thought it resolved it, but it really didn't.
    Added the resource-class in the Admin context:
    resource-class any-available
    limit-resource all minimum 0.00 maximum unlimited
    limit-resource sticky minimum 35.00 maximum equal-to-min
    no difference.

  • Question on CSS cookie sticky

    Hi everyone,
    I have a question about CSS cookie sticky.
    - Server issues the following cookie string to the client and it is fixed to 18 bytes.
    Set-Cookie: JSESSIONID=aaabbbcccdddeeefff; path=/
    - Client embedded the following cookie string in the subsequent HTTP header.
    Cookie: xx_user_id=ZZZZ03; com.dummy.xyz.session.cookie=|user|pc|ja|Shift_JIS|default||yellow|/oooo/default.portal|; JSESSIONID=aaabbbcccdddeeefff
    * Note that I made cookie information suitable as example.
    There is the cookie string (JSESSIONID=aaabbbcccdddeeefff) issued by Server in the HTTP header from client but that cookie string (JSESSIONID=aaabbbcccdddeeefff) is located following the cookie string that the client made by oneself at the end of cookie string. And the cookie string and the length of cookie string that client made by oneself might change so the total length of cookie string also might change. It means I can not clarify the total length of the cookie string.
    In this situation, I want CSS to stick with cookie string "JSESSIONID=aaabbbcccdddeeefff".
    The characters of string located following the "JSESSIONID=" (in this case, "aaabbbcccdddeeefff") might change but it is fixed to 18 bytes. The total length of cookie string is 141 bytes in above mentioned example.
    So I informed customer to configure the following parameters to get CSS done cookie sticky for above mentioned cookie string. CSS software version is sg0750303.
    owner test
    content testsv-tcp80
    add service testsv1-tcp80
    add service testsv2-tcp80
    advanced-balance cookie
     string range 1 to 200
    string process-length 18
    url "/*"
    redundant-index 1001
    protocol tcp
    port 80
    vip address xxx.xxx.xxx.xxx
    active
    However CSS was not able to treat the above mentioned cookie correctly which means the subsequent HTTP request was not stuck (persisted) to same server.
    I do not understand why CSS cookie sticky did not work correctly with this configuration.
    Then customer configured CSS with the following parameters to get CSS inserted cookie string and, of course, the result is OK that is CSS could stick the connection to same server.
    owner test
    content testsv-tcp80
    add service testsv1-tcp80
    add service testsv2-tcp80
    advanced-balance arrowpoint-cookie
    url "/*"
    redundant-index 1001
    protocol tcp
    port 80
    vip address xxx.xxx.xxx.xxx
    active
    Has anybody experienced similar thing ?
    Could you please let me know if you have any comment, information
    Your information would be appreciated.
    Best regards,

    the CSS does not learn dynamic cookie.
    You can match a fixed string inside a cookie and pre-define which server to use with that specific string.
    That's why your solution did not work.
    Arrowpoint-cookie is a better solution and easier to implement.
    Gilles.

  • Cookie stickiness configuration issue with Cisco ACE

                       Hi,
    We have configured a ACE (in standby mode) with ip netmask stickiness and wanted to configure cookie stickiness for a remedy server placed behind the ace. BMC has said that they use JSESSIONID field on the remedy application and i want to know the procedure for configuring ace to see this field and deploy cookie stickiness feature on the ace.
    We tried configuring the ace to learn the cookie string dynamically and tried to insert the cookie in the server response to the client but both methods have failed and the user is not able to see the remedy app webpage in both occassions.
    Are there any pre-requisites to be configured on the ace before configuring cookie stickiness feature?   We would appreciate your timely response.
    Thanks in advance.

    Hi,
    Refer the document below for sample configuration. If this still doesn't work a full config and sniffer capture required to verify this.
    http://docwiki.cisco.com/wiki/Session_Persistence_Using_Cookie_Learning_on_the_Cisco_Application_Control_Engine_Configuration_Example
    Regards,
    Siva

  • How to do http session stickiness based on URL patterns?

    Is there a feature within the WL plugin for Apache that would allow me to emulate the "jvmroute" session stickiness behaviour as provided by Tomcat and its plugin. I would like to have the control to tie requests from http clients to particular WLS servers in a cluster depending on the URL. For example http://foo.com/web01 requests would be forwarded to an appsererver app01 and so on. For all other requests (e.g http://foo.com/web), the WL plugin would do its normal load balancing ignoring the stickiness. From my understanding the WLS inbuilt http session stickiness is based on JSessionIDs which are exchanged using cookies - which is something i cannot use in my case since i want the stickiness based on URL patterns.
    I am using WLS 10.0 with Apache 2.2.4 on Linux.
    Thanks
    Ramdas

    Session is not replicated across all the servers in the Cluster.
    Apache knows which server to go using the JSession ID.
    There is a concept of primary and secondary, secondary is selected based on the replication groups there are configured in the cluster.
    you can configure the cluster so that /web01 requests go to different cluster, and /web requests go to different cluster.
    but you can get all the funtiionalities from the single cluster.
    Do you have any java caching that you are not able to replicate across the cluster ?(I know this can be done too).
    let me know what you are actually trying to solve by doing the behavior you explained.

  • Catalyst 6500 CSM-S Cookie stickiness timout ?

    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin-top:0cm;
    mso-para-margin-right:0cm;
    mso-para-margin-bottom:10.0pt;
    mso-para-margin-left:0cm;
    line-height:115%;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    Hi, anyone able to help with this ?
    We have a CSM-S sitting in a 6513, at the moment we have IP stickiness applied for a Vserver/Serverfarm. The back end product vendor advises that cookie stickiness would be more appropriate for their application.
    I have been scratching my head around the timeout of the inserted cookies; whatever I do they persist seemingly indefinitely, for example:
    Just a test configuration with a 10minute sticky timout.
    serverfarm applicationA
      nat server
      nat client applicationA_pool
      failaction reassign
      real 1.1.1.1
       inservice
      real 1.1.1.2
       inservice
      health retries 1 failed 120
      probe applicationA_probe
    sticky 1 cookie applicationA_sticky insert timeout 10
    vserver applicationA-HTTP
      virtual 2.2.2.10 tcp www
      unidirectional
      serverfarm applicationA
      sticky 10 group 1
      no persistent rebalance
      inservice
    Doing show mod csm 1 sticky
    group   sticky-data              real                  timeout
    1       cookie F5BF7115:F80EA688 1.1.1.1           0
    1       cookie 4AFC972B:BB722437 1.1.1.2           0
    Then a show mod csm 1 sticky config
    Group  NumEntries Timeout  Type
    1             82                           10        cookie-insert applicationA_sticky
    When browsing to the VIP I see the application page via one of the reals. For the sake of the test I am using round-robin. Without cookies applied my browser will bounce between reals (I turned off persistent rebalance during testing) as expected.
    With a sticky cookie inserted the browser stays on one of the real’s, however the timeout which I have applied does not work. The client will stay stuck to the real almost indefinitely (the actual cookie expiry is 2099!).
    The online documentation advised that the method I am using should work as expected:
    Quote
    This example shows how to configure a virtual server named barnett, associate it with the server farm named bosco, and configure a sticky connection with a duration of 50 minutes to sticky group 12:
    Router(config)# mod csm 2
    Router(config-module-csm)# sticky 1 cookie foo timeout 100
    Router(config-module-csm)# exit
    Router(config-module-csm)#
    Router(config-module-csm)# serverfarm bosco
    Router(config-slb-sfarm)# real 10.1.0.105
    Router(config-slb-real)# inservice
    Router(config-slb-real)# exit
    Router(config-slb-sfarm)#
    Router(config-slb-sfarm)# vserver barnett
    Router(config-slb-vserver)# virtual 10.1.0.85 tcp 80
    Router(config-slb-vserver)# serverfarm bosco
    Router(config-slb-vserver)# sticky 50 group 12
    Router(config-slb-vserver)# inservice
    Router(config-slb-vserver)# exit
    Router(config-module-csm)# end
    End Quote
    I am guessing that sticky group 12 / 1 is a typo
    Looking at the documentation, sticky can also be applied not in the vserver config but in a policy (this is how we are doing IP stickiness). I have tried both methods. Same result.
    I am natting the client address to a private pool which then talks to the reals (and back). Would'nt expect this to be any issue.
    The CSM is running Software version: 4.3(5).
    Any help appreciated.

    Good mornign Simon,
    The behavior you are seeing is the expected one.
    When the CSM is configured for cookie insertion, a static cookie value is created in the sticky table for each server. This is the cookie that is being inserted, using as expiration date the one defined in the COOKIE_INSERT_EXPIRATION_DATE variable.
    With this stickiness method, there is no need to use a timeout, because, since the sticky table will only contain one entry for each server, it will never become full.
    Quoting from the documentation:
    Note     The
    configurable timeout values are not applied when using cookie insert. 
    You can adjust the timeout value using the environment variables.
    If you don't want to keep the cookies in the client for that long, another approach you can use is setting an empty date in the COOKIE_INSERT_EXPIRATION_DATE variable. When doing that, the cookie will be inserted without an expiration date, so it will be cleared when the browser is closed.
    I hope this answers your question
    Regards
    Daniel

  • Cookie stickiness on ACE

    Hi:
    I have the following configuration. Although the users can hit the web server, the stickiness doesn't work.
    sticky http-cookie TEST1 TEST1
    timeout 300
    replicate sticky
    serverfarm PROXY
    policy-map type loadbalance first-match L7_TEMPORAL
    class HTTP-TEMPORAL
    sticky-serverfarm TEST1
    policy-map multi-match L4-VIP-LB-Policy
    class VIP-TEMPORAL
    loadbalance policy L7_TEMPORAL
    Raul

    Not sure if you already did that but to make stickiness work you need to assign resources for stickiness per context. Have look at the link.
    http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_guide_chapter09186a0080686ebf.html#wp1051078
    sticky http-cookie TEST1 TEST1 says the ace is looking for a cookie named "TEST1" in the http header so you should make sure that cookie exists. Otherwise add a "cookie insert" and the ace should insert that a cookie named "TEST1" then.
    http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_guide_chapter09186a0080686ebf.html#wp1015713
    [quote]
    The name argument in the sticky command specifies the cookie name that appears in the HTTP header. The name argument in the cookie secondary command specifies the cookie name that appears in the URL.
    [/quote]
    Roble

  • 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,
    Yves

    Hi 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...

  • ACE cookie stickiness issue

    Hi,
    We are having ACE as the load balancer
    Software running on ACE
    loader: Version 12.2[121]
    system: Version A2(1.1a) [build 3.0(0)A2(1.1a) adbuild_22:19:41-2008/07/21_
    /auto/adbu-rel3/rel_a2_1_1_throttle/REL_3_0_0_A2_1_1A]
    system image file: [LCP] disk0:c6ace-t1k9-mz.A2_1_1a.bin
    We have 2 webservers (load balanced) & 2 application servers(load balanced).Cookie based stickiness is currently used on Web & Application servers.
    Ideal scenario:
    1.Client opens the url http://...There is always a dual session whenever the client opens the url.One is for Java & the other for html.
    2.Client--->Webserver1
    3.Webserver1---->APP1
    Most of the times when the client types the url, the dual sessions goes to one Webserver as per round robin (eg web server 1) & the webserver 1 communicates with Application server as per round robin (eg.application server 1).
    Problem:
    Now at times when the client types the url, the dual sessions gets split which means one session goes to one webserver & the other session goes to second webserver.Ideally it should not as per the application demands.
    When this happens, both the webservers communicates with both the application servers.Here is where the problem happens.The client is asked for the login page again which indicates that the client has went to the second application server for the login.
    What ideally should happen is the client should stick to the same application server depending up the sticky timeout.
    Foll. is the output of show conns when prob occurs:
    Primary-ACE/DMZ2# sh conn serverfarm SF-8888
    conn-id np dir proto vlan source destination state
    ----------+--+---+-----+----+---------------------+---------------------+------+
    1321 1 in TCP 2504 172.21.46.34:2037 172.24.51.200:8888 ESTAB
    1255 1 out TCP 2704 172.24.51.33:8888 172.21.46.34:2037 ESTAB
    1108 2 in TCP 2504 172.21.46.34:2036 172.24.51.200:8888 ESTAB
    1144 2 out TCP 2704 172.24.51.32:8888 172.21.46.34:2036 ESTAB
    Primary-ACE/APP# sh conn serverfarm SF-8888
    conn-id np dir proto vlan source destination state
    ----------+--+---+-----+----+---------------------+---------------------+------+
    959 2 in TCP 2507 172.24.51.32:58306 172.24.54.200:8888 ESTAB
    115 2 out TCP 2707 172.24.54.32:8888 172.24.51.32:58306 ESTAB
    651 2 in TCP 2507 172.24.51.33:51030 172.24.54.200:8888 ESTAB
    901 2 out TCP 2707 172.24.54.33:8888 172.24.51.33:51030 ESTAB
    I have attached the configs.
    The web server we are testing is 172.24.51.32 & 33 - port 8888
    Application servers - 172.24.54.32 & 33-port 8888
    Rgds./Sachin

    Sachin~
    What is exactly your flow?
    Is client hitting the Webserver farm (in web server context) and then Web servers hitting the APPs Servers in the APPS server context?
    If thats the case (only Web servers are App server clients and client is not hitting application serverfarm ) then you can use source ip based sticky in APP server farm which will ensure that one web server sticks to a particular APP server and it never changes the APP server.
    Following example will insert cookie named "Mycookie" in the server responses from APP1 rservers to the client
    rserver host App1-Srvr1
    ip address 192.168.1.1
    inservice
    rserver host App1-Srvr2
    ip address 192.168.1.2
    inservice
    serverfarm host APP1-SFARM
    rserver App1-Srvr1
    inservice
    rserver App1-Srvr2
    inservice
    class-map match-any APP1-VIP
    2 match virtual-address 10.10.10.1 tcp eq www
    sticky http-cookie MYcookie App1-sticky
    cookie insert
    timeout 720
    replicate sticky
    serverfarm App1-Sfarm
    policy-map type loadbalance first-match APP1-POLICY
    class class-default
    sticky-serverfarm App1-sticky
    policy-map multi-match VIPS
    class VIP-P80
    loadbalance vip inservice
    loadbalance policy APP1-POLICY
    loadbalance vip icmp-reply active
    HTH
    Syed Iftekhar Ahmed

  • 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,
    george

    This 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.

  • How to read http cookies from adobe desktop Air app using flex/flash builder in AS 3.0 ??

    Im developing Adobe desktop air app where i need to read the session id from the cookie of a http request.
    I have found a property called URLRequest.manageCookies supported by AIR so i Hope there should be a way to read the cookies as well. Im Using Flash Builder 4.5
    Please provide any reference code or guide me for this research;
    searched a lot regarding on this web.
    Most results lead to local shared object or reading cookies fr a webpage using javascript and ExternalInterface.
    I want to read http cookies not Local shared Object and in a desktop AIR application.
    Im using Flash builder 4.5
    Thanks
    Hari

    Sorry, but you are at the wrong forum; this one is only for discussions on the forums themselves. The Air forums are here:
    http://forums.adobe.com/community/air

  • How to set HTTP cookie ORA_adf_viewScope

    Hi,
    I'm recording ADF page navigation using LoadRunner. From the browser, I see that one POST request sets http cookie ORA_adf_viewScope and the subsequent GET submits this cookie as part of the HTTP header. I don't see this cookie from any of the page source. LoadRunner is not able to record this cookie as well. Hence when I replay LR script, the GET request returns wrong page.
    Any one knows how to set this cookie?
    Thanks,
    Tong
    Edited by: user708470 on Jun 18, 2009 12:07 PM

    I believe it is possible since axis adapter provides very same functionality. Let me summarize my scenario may be it helps:
    I am trying to call series of webservice lets say in a BPM. First service (login service) will provide me with a session id (in http header with key Set-Cookie) then I will call another service which has that session id in its http header with key cookie then I am going to logout. So I am testing the second part now, but it doest let me send cookie http header parameter.
    I hope I clarified a bit more my problem.
    Regards,

  • I want to use HTTP Cookies but it is disable,what should I do?

    I want to login in a university site but when I enter the ID and PIN ,this massage has been shown: "This system requires the use of HTTP cookies to verify authorization information. Our system has detected that your browser has disabled HTTP cookies, or does not support them."
    I dnt know what to do please help me.

    See:
    * [[Cookies]]
    * [[Enabling and disabling cookies]]

Maybe you are looking for