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

Similar Messages

  • ACE cookie stickiness

    Is there a way for the ACE to read the cookie value if it has a period in it (.).  For example the cookie is ASP.NET_SessionID.  The ACE appears to be ignoring the (.).  I know I can switch to cookie insert, but was curious if I can work with the (.) in case this comes up in the future.

    Is there a way for the ACE to read the cookie value if it has a period in it (.).  For example the cookie is ASP.NET_SessionID.  The ACE appears to be ignoring the (.).  I know I can switch to cookie insert, but was curious if I can work with the (.) in case this comes up in the future.

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

  • 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

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

  • ACE Cookie insert behavior

    Hi ,
    My requirement is as follows
    i have following url
    http://x.x.x.x/abc
    http://x.x.x./dce
    http://x.x.x.x/fgh
    only for http://x.x.x.x/abc should be using stickiness based on http cookie insert remaining all it should use ip based stickiness.
    problem what i am facing is ,
    if i access http://x.x.x.x/dce , it is not showing any COOKIE in the header ( which is as expected ) and when i access http://x.x.x./abc it showing the inserted COOKIE (again expected) , but when i am accessing the url http://x.x.x.x/dce or fgh again , it is still showing the INSERTED COOKIE  is it a known behaviour?.
    as far as i understand , before the session  request , ACE maintains the insert cookie values in the cookie database and thus it is less processing intensive.
    However , why is it inserting to all request , even though i am not configuring as such .
    following is my configuration  , is it a known behaviour or is it the way it should work?
    serverfarm host SF-FOR-DCE
      probe TCP_8032
      rserver MYSERVER1 8032
        inservice
      rserver MYSERVER2 8032
        inservice
    serverfarm host SF-FOR-FGH
      probe TCP_8083
      rserver MYSERVER1 8083
        inservice
      rserver MYSERVER2  8083
        inservice
    serverfarm host SF-FOR-ABC
      probe TCP_8081
      rserver MYSERVER1 8081
        inservice
      rserver MYSERVER1 8081
        inservice
    sticky http-cookie COOKIE-SKYCHAIN STICKY-ABC
      cookie insert browser-expire
      timeout 720
      replicate sticky
      serverfarm SF-FOR-ABC
    sticky ip-netmask 255.255.255.0 address source STICKY-DCE
      timeout 720
      replicate sticky
      serverfarm SF-FOR-DCE
    sticky ip-netmask 255.255.255.0 address source STICKY-EFG
      timeout 720
      replicate sticky
      serverfarmSF-FOR-FGH
    class-map type http loadbalance match-all CM7-1
      2 match http url /dce/*.*
    class-map type http loadbalance match-all CM7-2
      2 match http url /fgh/*.*
    class-map type http loadbalance match-all CM7-3
      2 match http url /abc*.*
    policy-map type loadbalance first-match PM7-1
      class CM7-1
        sticky-serverfarm STICKY-DCE
      class CM7-2
        sticky-serverfarm STICKY-EFG
      class CM7-3
        sticky-serverfarm STICKY-ABC
    class-map match-any CM3-VIP
      3 match virtual-address x.x.x.x tcp eq www
    policy-map multi-match PM34-VIP
    class CM3-VIP
        loadbalance vip inservice
        loadbalance policy PM7-1
        loadbalance vip icmp-reply
    Assistance appreciated.
    thanks
    -PMD

    Are you seeing the client still send the cookie when going to the other locations /DCE or /FGH, or are you seeing the ACE insert the cookie? If you are only seeing the client still sending the cookie this is expected behavior. The cookie is issued for the path / so if the client learned the cookie from the domain x.x.x.x it will send the cookie any time it goes to that domain regardless of the path that is being used.
    Regards
    Jim

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

  • Session Stickiness Issue

    Hi All,
    I am facing session stickiness issue where we have four webserver instances and six weblogic instances.
    If you see in the failure logs the JVM ID generated by the cookie is 1872775671 but the plugin is routing the request to 923706867.Please find below
    Please find the success and failure logs below
    Proxy Error Log :
    ================New Request: [amserver/UI/Login] =================
    Wed Mar 20 15:01:10 2013 <202911363806070191> Uri as read from rq (request) data structure /amserver/UI/Login
    Wed Mar 20 15:01:10 2013 <202911363806070191> Uri after pathTrim /amserver/UI/Login
    Wed Mar 20 15:01:10 2013 <202911363806070191> Uri resolved to /amserver/UI/Login?module=GMACLoginModule&org=branch
    Wed Mar 20 15:01:10 2013 <202911363806070191> resolveRequest return code is [0]
    Wed Mar 20 15:01:10 2013 <202911363806070191> URI=[amserver/UI/Login?module=GMACLoginModule&org=branch]
    Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: SSL is not configured
    Wed Mar 20 15:01:10 2013 <202911363806070191> Found cookie from cookie header: JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671
    Wed Mar 20 15:01:10 2013 <202911363806070191> Parsing cookie JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671
    Wed Mar 20 15:01:10 2013 <202911363806070191> getpreferredServersFromCookie: [-1872775671]
    Wed Mar 20 15:01:10 2013 <202911363806070191> primaryJVMID: [-1872775671]
    secondaryJVMID: []
    Wed Mar 20 15:01:10 2013 <202911363806070191> No of JVMIDs found in cookie: 1
    Wed Mar 20 15:01:10 2013 <202911363806070191> Trying to locate Primary or Secondary using SrvrInfo with JVMID: 923706867
    Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Start Position is 0, listLen is 1
    Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Either JVMIDs not set or they are stale. Will try to get JVMIDs from WLS
    Wed Mar 20 15:01:10 2013 <202911363806070191> initJVMID: Iterating SrvrList from position 0
    Wed Mar 20 15:01:10 2013 <202911363806070191> ======internal request /bea_wls_internal/WLDummyInitJVMIDs======
    initJVMID: Trying Host[10.13.52.81] Port[7005] SecurePort[7006] useSSL [0] ioTimeout [30] socketTimeout [10]
    Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: New NON-SSL URL
    Wed Mar 20 15:01:10 2013 <202911363806070191> Connect returns -1, and error no set to 245, msg 'Operation now in progress'
    Wed Mar 20 15:01:10 2013 <202911363806070191> EINPROGRESS in connect() - selecting
    Wed Mar 20 15:01:10 2013 <202911363806070191> Local Port of the socket is 63476
    Wed Mar 20 15:01:10 2013 <202911363806070191> Remote Host 10.13.52.81 Remote Port 7005
    Wed Mar 20 15:01:10 2013 <202911363806070191> URL::sendHeaders(): meth='HEAD' file='/bea_wls_internal/WLDummyInitJVMIDs' protocol='HTTP/1.0'
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Connection]=[Close]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Request-ClusterInfo]=[true]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Force-JVMID]=[unset]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-KeepAliveSecs]=[30]
    Wed Mar 20 15:01:10 2013 <202911363806070191> URL::parseHeaders: CompleteStatusLine set to [HTTP/1.1 400 Bad Request]
    Wed Mar 20 15:01:10 2013 <202911363806070191> URL::parseHeaders: StatusLine set to [400 Bad Request]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Date]=[Wed, 20 Mar 2013 19:01:10 GMT]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Content-Length]=[897]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Content-Type]=[text/html]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[X-WebLogic-Cluster-Hash]=[7GHstOoW2dPEsRHcWrZe05SfKAc]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[X-WebLogic-Cluster-List]=[923706867!168637521!7005!7006]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from WLS:[Connection]=[Close]
    Wed Mar 20 15:01:10 2013 <202911363806070191> parsed all headers OK
    Wed Mar 20 15:01:10 2013 <202911363806070191> initJVMID: Received the same cluster-list. Returning with no preferred servers found.
    Wed Mar 20 15:01:10 2013 <202911363806070191> .....internal request /bea_wls_internal/WLDummyInitJVMIDs.....processed
    Wed Mar 20 15:01:10 2013 <202911363806070191> getPreferredFromCookie: Found 0 servers
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept]=[image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[referer]=[https://capacity.dealerservices.ally.com/userprovisioning/jsp/autoSubmit.jsp?lang=en-us&source=MigratedLoginWidget&userType=branch&process=login]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept-language]=[en-US]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; BTRS99959; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[accept-encoding]=[gzip, deflate]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[host]=[gdpcapacity.gmacbranch.gmac.gm.com]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[cache-control]=[no-cache]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[cookie]=[s_pers=%20s_ts%3D%255B%255B%2527BRA0006T%2527%252C%25271362265430952%2527%255D%252C%255B%2527BRA0005T%2527%252C%25271363804235955%2527%255D%255D%7C1521570635955%3B%20s_nr%3D1363805063050-Repeat%7C1366397063050%3B; Locale=en-us; MasterCookie=MasterCookie; GDP_screenHeight=768; GDP_screenWidth=1366; GDP_browserType=Microsoft%20Internet%20Explorer; GDP_browserVersion=4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; GDP_operatingSystem=Win32; GDP_userAgent=Mozilla/4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671; ObSSOCookie=tKGxD0YS6sUw8kyVwfVBNujGihNvtG5GlUrYljs%2F3fngJbUm4%2B1bA6FpLn3LEESIpQsqwhjMDZODuautF%2B7zHKXypTkT%2Fn8DwdGn%2FYZOJK49wBTU511DfkqBmqBMsGjSM42jobA5gSQ672vUQskytWaJc4tZQC7MDLOGPEJf%2Bwc%2BVtXRi1%2FRGI4ql8jQpyWSJP6ImkHwt6QNig3Vlyt9BLZws6vvgHulULaxuA%2BXfUZ4fkVaVwN35tAmWorUa1ODiORCWhVSrZybMhTk53NsjT%2FdOaXFLZM4wcj6PKVkeG1UtZVfoNuVw8LBBVd5ave0]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[gmacdealer_groups]=[smartcash:scsupervisor:branch:us:en-us:EOAdminUS:]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[HTTP_OBLIX_UID]=[cbrus16]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs from Client:[HTTP_OBLIX_UID]=[cbrus16]
    Wed Mar 20 15:01:10 2013 <202911363806070191> attempt #0 out of a max of 5
    Wed Mar 20 15:01:10 2013 <202911363806070191> Server details are ''/0/0
    Preferred server not set or was marked bad, checking next preferred server
    Wed Mar 20 15:01:10 2013 <202911363806070191> Server details are ''/0/0
    Preferred server not set or was marked bad, checking next preferred server
    Wed Mar 20 15:01:10 2013 <202911363806070191> Trying a pooled connection for '10.13.52.81/7005/7006'
    Wed Mar 20 15:01:10 2013 <202911363806070191> getPooledConn: No more connections in the pool for Host[10.13.52.81] Port[7005] SecurePort[7006]
    Wed Mar 20 15:01:10 2013 <202911363806070191> general list: trying connect to '10.13.52.81'/7005/7006 at line 1676 for '/amserver/UI/Login?module=GMACLoginModule&org=branch'
    Wed Mar 20 15:01:10 2013 <202911363806070191> INFO: New NON-SSL URL
    Wed Mar 20 15:01:10 2013 <202911363806070191> Connect returns -1, and error no set to 245, msg 'Operation now in progress'
    Wed Mar 20 15:01:10 2013 <202911363806070191> EINPROGRESS in connect() - selecting
    Wed Mar 20 15:01:10 2013 <202911363806070191> Local Port of the socket is 63477
    Wed Mar 20 15:01:10 2013 <202911363806070191> Remote Host 10.13.52.81 Remote Port 7005
    Wed Mar 20 15:01:10 2013 <202911363806070191> general list: created a new connection to '10.13.52.81'/7005 for '/amserver/UI/Login?module=GMACLoginModule&org=branch', Local port: 63477
    Wed Mar 20 15:01:10 2013 <202911363806070191> WLS info : 10.13.52.81:7005 recycled? 0
    Wed Mar 20 15:01:10 2013 <202911363806070191> URL::sendHeaders(): meth='GET' file='/amserver/UI/Login?module=GMACLoginModule&org=branch' protocol='HTTP/1.1'
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept]=[image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[referer]=[https://capacity.dealerservices.ally.com/userprovisioning/jsp/autoSubmit.jsp?lang=en-us&source=MigratedLoginWidget&userType=branch&process=login]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept-language]=[en-US]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[user-agent]=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; BTRS99959; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[accept-encoding]=[gzip, deflate]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[host]=[gdpcapacity.gmacbranch.gmac.gm.com]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[cache-control]=[no-cache]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[cookie]=[s_pers=%20s_ts%3D%255B%255B%2527BRA0006T%2527%252C%25271362265430952%2527%255D%252C%255B%2527BRA0005T%2527%252C%25271363804235955%2527%255D%255D%7C1521570635955%3B%20s_nr%3D1363805063050-Repeat%7C1366397063050%3B; Locale=en-us; MasterCookie=MasterCookie; GDP_screenHeight=768; GDP_screenWidth=1366; GDP_browserType=Microsoft%20Internet%20Explorer; GDP_browserVersion=4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; GDP_operatingSystem=Win32; GDP_userAgent=Mozilla/4.0%20%28compatible%3B%20MSIE%208.0%3B%20Windows%20NT%206.1%3B%20Trident/4.0%3B%20BTRS99959%3B%20SLCC2%3B%20.NET%20CLR%202.0.50727%3B%20.NET%20CLR%203.5.30729%3B%20.NET%20CLR%203.0.30729%3B%20Media%20Center%20PC%206.0%3B%20MS-RTC%20LM%208%3B%20.NET4.0C%3B%20InfoPath.3%29; JSESSIONID=RKHWGqJvmJGWgZ9YdqywsXBLRd7QtMGX1Qr1yTmNTn0Kcdq0M0xq!-1872775671; ObSSOCookie=tKGxD0YS6sUw8kyVwfVBNujGihNvtG5GlUrYljs%2F3fngJbUm4%2B1bA6FpLn3LEESIpQsqwhjMDZODuautF%2B7zHKXypTkT%2Fn8DwdGn%2FYZOJK49wBTU511DfkqBmqBMsGjSM42jobA5gSQ672vUQskytWaJc4tZQC7MDLOGPEJf%2Bwc%2BVtXRi1%2FRGI4ql8jQpyWSJP6ImkHwt6QNig3Vlyt9BLZws6vvgHulULaxuA%2BXfUZ4fkVaVwN35tAmWorUa1ODiORCWhVSrZybMhTk53NsjT%2FdOaXFLZM4wcj6PKVkeG1UtZVfoNuVw8LBBVd5ave0]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[gmacdealer_groups]=[smartcash:scsupervisor:branch:us:en-us:EOAdminUS:]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[HTTP_OBLIX_UID]=[cbrus16]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[HTTP_OBLIX_UID]=[cbrus16]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Path-Translated]=[u001/webserver/docs/gdp-capacity-backend-sec/amserver/UI/Login]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Path-Translated-Base]=[u001/webserver/docs/gdp-capacity-backend-sec]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-Keysize]=[128]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-Secretkeysize]=[128]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-Client-IP]=[129.41.252.30]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[WL-Proxy-SSL]=[true]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Proxy-Client-IP]=[129.41.252.30]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-Forwarded-For]=[129.41.252.30]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[Connection]=[Keep-Alive]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-KeepAliveSecs]=[30]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[X-WebLogic-Request-ClusterInfo]=[true]
    Wed Mar 20 15:01:10 2013 <202911363806070191> Hdrs to WLS:[x-weblogic-cluster-hash]=[7GHstOoW2dPEsRHcWrZe05SfKAc]
    Wed Mar 20 15:01:11 2013 <202911363806070191> URL::parseHeaders: CompleteStatusLine set to [HTTP/1.1 302 Moved Temporarily]
    Wed Mar 20 15:01:11 2013 <202911363806070191> URL::parseHeaders: StatusLine set to [302 Moved Temporarily]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Date]=[Wed, 20 Mar 2013 19:01:10 GMT]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Pragma]=[no-cache]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Location]=[https://gdpcapacity.gmacbranch.gmac.gm.com/portal/dt?action=process&provider=PortletWindowProcessChannel&windowProvider.targetPortletChannel=GMACDataProvider&containerName=GMACBranchHomeContainer&windowProvider.currentChannelMode=VIEW&window.portletAction=ACTION]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Content-Type]=[text/html]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Expires]=[0]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[JSESSIONID=RKHW4QzDhbJpcQJJpXJ21CV3lxY2lbhNJYmtJCYGGK2BC71JTqGr!923706867; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[iPlanetDirectoryPro=AQIC5wM2LY4Sfcwgaa%2Bz8dzyN5AAXxW2GEBHoRwWjfYUb9M%3D%40AAJTSQACMDI%3D%23; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Set-Cookie]=[AMAuthCookie=LOGOUT; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[X-AuthErrorCode]=[0]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[X-DSAMEVersion]=[6 2005Q1]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Transfer-Encoding]=[chunked]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs from WLS:[Cache-Control]=[private]
    Wed Mar 20 15:01:11 2013 <202911363806070191> parsed all headers OK
    Wed Mar 20 15:01:11 2013 <202911363806070191> sendResponse() : uref_p->getStatus() = '302'
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[date]=[Wed, 20 Mar 2013 19:01:10 GMT]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Pragma]=[no-cache]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Location]=[https://gdpcapacity.gmacbranch.gmac.gm.com/portal/dt?action=process&provider=PortletWindowProcessChannel&windowProvider.targetPortletChannel=GMACDataProvider&containerName=GMACBranchHomeContainer&windowProvider.currentChannelMode=VIEW&window.portletAction=ACTION]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[content-type]=[text/html]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Expires]=[0]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[JSESSIONID=RKHW4QzDhbJpcQJJpXJ21CV3lxY2lbhNJYmtJCYGGK2BC71JTqGr!923706867; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[iPlanetDirectoryPro=AQIC5wM2LY4Sfcwgaa%2Bz8dzyN5AAXxW2GEBHoRwWjfYUb9M%3D%40AAJTSQACMDI%3D%23; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Set-Cookie]=[AMAuthCookie=LOGOUT; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[X-AuthErrorCode]=[0]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[X-DSAMEVersion]=[6 2005Q1]
    Wed Mar 20 15:01:11 2013 <202911363806070191> Hdrs to client (add):[Cache-Control]=[private]
    Wed Mar 20 15:01:11 2013 <202911363806070191> canRecycle: conn=1 status=302 isKA=1 clen=-1 isCTE=1
    Wed Mar 20 15:01:11 2013 <202911363806070191> closeConn: pooling for '10.13.52.81/7005'
    Wed Mar 20 15:01:11 2013 <202911363806070191> request [amserver/UI/Login?module=GMACLoginModule&org=branch] processed successfully..................
    Could some one let me know how to maintain the session stickiness and please do let me know why the JVM ID is getting changed.
    Note : We are using cookie based replication in our environment.
    Thanks & Regards
    Arun

    the CSS does not have the possibility to dynamically learn cookie.
    So, you have to setup manually the value sent by each server.
    According to your setup, the jsessionid would have a fix value after the first 33 bytes and the value will be 2 bytes long.
    Is that correct ?
    If yes, try to increase the string range.
    Finally, it might be easier to use arrowpoint cookies.
    Gilles.

  • 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

  • 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

  • ACE SSL Sticky class-map generic vs class default differences.

    There was a thread recently titled "ACE 3.0(0) SW / LB with SSL Session-ID" where Giles Dufour outlined a configuration for an ACE performing sticky based on SSL Session ID.
    Can anyone explain the benefits and differences of using a specific class-map generic such as this:
    class-map type generic match-any SSL-v3-32
      2 match layer4-payload regex "\x16\x03\x00..\x01.*"
      3 match layer4-payload regex "\x16\x03\x01..\x01.*"
    Versus just matching class default?
    So if I have a configuration such as this:
    policy-map type loadbalance generic first-match SSL-v3-Sticky
    class SSL-v3-32
       sticky-serverfarm ssl-v3
    vs
    policy-map type loadbalance generic first-match SSL-v3-Sticky
    class class-default
       sticky-serverfarm ssl-v3
    What's the benefit or drawback?

    The SSL session id is only available in version 3.0.1 and 3.1.1
    So you can match this particular version and then attempt to do stickyness.
    You are guaranteed to find what you're looking for.
    If you match a class-default it means you apply stickyness to any version of ssl packet.
    So there is a risk to misinterpret the content of the packet and stick on something else than the session id.
    Gilles.

  • Cisco GSS - Cookie Stickiness

    Hi,
    What all the parameters can be used for stickiness across different data centers via Cisco
    GSS. Is cookie stickiness possible.
    We are planning to implement an Active/Active site and the
    internet user requests will be load balanced across two sites. Since most of the users use ADSL connections, the source IPs are dynamic and changes within minutes and even seconds. If the stickiness would be configured based on IPs on the GSS, the sessions would be lost due to continuous IP changes and the user would be randomly directed to different data centers.
    Please suggest how could stickiness be achieved without IPs.
    Thanks.

    Hello there,
    Stickiness on the GSS is based on IP address.  There is local sticky, which means each GSS in the cluster maintains its own sticky database and doesn't share it with the other GSS in the cluster.  Global sticky is when each still has its own sticky database, but they update each GSS in the cluster so that if a request comes into a different GSS from the same host IP and requests the same domain, it will still be stuck to the same Answer.
    It does not matter if your clients are frequently changing their IP addresses, because an Internet user's IP address is not used, or known, by the GSS.  To the GSS, a client is actually an Internet user's D-proxy, or local DNS server.  Here's how it works:
    Internet user needs to resolve FQDN to IP address
    Internet user sends DNS query to his/her DNS server (D-proxy)
    D-proxy (which typically has a static IP address) makes request throughout DNS infrastructure sourced by its own IP address
    Eventually, the DNS request ends up at a GSS
    GSS checks to see if it already has a sticky entry for the IP address of this D-proxy
    If sticky entry exists, then the same Answer is given as last time
    If sticky entry does not exist, GSS will use configured method to choose Answer, return it, then create sticky entry
    If you are using global sticky, then the GSS will update the other GSS in cluster so they add the entry to their databases
    So as you can see, the Internet user's IP address has no relevance to the GSS's operation.
    I hope this helps.  Let me know if you have any questions.
    Thank you,
    Sean

  • Using TACACS+ auth from ACS 5.1.0.44 to ACE. Having Issues with Shell (Exec)

    Using TACACS+ auth from ACS 5.1.0.44 to ACE. Having Issues with Shell (Exec)
    So I am trying to get TACACS+ auth to work for my ACE.
    The command string that I have on the ACE is as follows:
    tacacs-server host 172.16.101.4 key 7 XXXYYYZZZ timeout 15
    aaa group server tacacs+ tacacs+
      server 172.16.101.4
    aaa authentication login default group tacacs+ local
    aaa authentication login console local
    aaa accounting default group tacacs+ local
    But to finish getting this enabled I need to create some sort of shell (exec) string in the ACS that tells the ACE what permission level to allocate.
    I do not know how to do this on the ACS 5.1.0.44.
    Anyone know?
    TAC made a good suggestion but the command path doesn't seem to line up with my version of ACS.
    Thanks for your reply. About this question:
    shell:<Context>*<Role> <Domain>
    What I meant is that you need to check the following couple of things on
    your ACS server in order to have AAA Tacacs users to login into the
    ACE over the context with superuser ritghts.
    Group setup ‑> users ‑> TACACS + Settings ‑> enable Shell(exec)
    ‑> enable Custom attributes ‑> right below this part you need to
    use the following sintax to link the ACE context that this user
    has access to.
    For example:
    shell:<Context>*<Role> <Domain>
    shell:Admin*Admin default‑domain
    Where this user will have access to the Admin context with the role
    admin using the 'default‑domain'

    Wilfred,
    What you will have to do on your version of ACS is modify the shell profile that your admins are hitting for other IOS devices or you can create another shell profile under Policy Elements -> Device Administration ->
    Once you get into this shell profile select the Custom Attributes tab and put in the following fields close to the bottom of the screen, from the example you provided type shell:Admin for the attribute field and then default-domain for the value field, and make sure you select this requirement as optional, if you select mandatory and other IOS devices use this same shell profile you will force this av pair to these devices also which will impact the priv levels that then need for authentication.
    After you add this attribute, save your changes and then test, also make sure that your Aceess Policy is calling this shell profile under the authorization profile for default device admin.
    Thanks,
    Tarik Admani

  • Csm cookie sticky

    Hello Gilles,
    I have setup cookie stickiness using the following config:
    sticky 1 cookie JSESSIONID timeout 100
    serverfarm xxxxx
    real 192.168.1.1
    health probe HTTP01
    inservice
    real 192.168.1.2
    health probe HTTP02
    inservice
    policy pol_IOW_stick
    serverfarm xxxxxx
    sticky-group 1
    vserver yyyyyy
    virtual 192.168.1.5 tcp 0
    serverfarm xxxxx
    replicate csrp sticky
    replicate csrp connection
    persistent rebalance
    slb-policy POL_IOW_STICK
    inservice
    Load balancing is working to the real servers and I can see the policy being matched, however,
    I never see any entries in the sticky table.
    This is a test scenario and all connections are being proxied through 2x proxy servers. Should I
    not see at least the ip addresses of both proxy servers in the sticky table?
    We are running version CSM v3.1(4)
    Thanks

    you need 4.x to see the sticky entry when using something else than sticky source ip.
    Stickyness shoud work, it's just the show commands that requires CSM version 4.x
    Regards,
    Gilles.

  • ACE Sticky issue.

    Hi,
    The Sticky function of the ACE is not working. There were no changes been made on the device it was working fine before but not now,.
    We have 2 ACE one is Active(ACE1) and Second one is Standby (ACE2).
    Testing done till now:-
    ================
    Done the Failover from Active(ACE1) to Standby (ACE2).
    When ACE2 was Active the Sticky started working fine without any issues.
    2)  when I did the failover again back from ACE2 to ACE1 the problem arrise Sticky doesnt work any more.
    Any suggestion about this strange behaviour?
    Thanks in advance.
    Regards
    Alex.

    What version do you run ?
    What type of sticky method ?
    Could you get a
    - show np 1 me-stats "-slb"
    and a
    - show np 2 me-stats "-slb"
    Possibly get 2 occurences one before and one after a test.
    Thanks,
    Gilles.

Maybe you are looking for